Views vs Viewpoints?!

Started by s_derix, March 10, 2021, 12:44:11 PM

Previous topic - Next topic

s_derix

Hi!

I'm new to this forum and pretty new to Archi.

My problem:
- when/why do i create new views in the views folder
- when do I use the Viewpoints (of a view) via the menu

I've added an attachment that hopefully explains more.

TIA!

Regards,
Sander


Jean-Baptiste Sarrodie

Hi,

Welcome to the forum.

First, I'd suggest you to read this chapter of the ArchiMate 101. It covers the difference between views and viewpoints in a more generic way and addresses (at the end of the section) the question of the tools.

So...

Quote
- when/why do i create new views in the views folder

The underlying logic in ArchiMate standard is thatt, most of the time, you interact with the model through views. So you create views (diagrams) based on the needs of your stakeholders, either adhoc or as part of an architecture description.

Quote
- when do I use the Viewpoints (of a view) via the menu

The viewpoint attribute allows you to classify or type your views. This makes it easier to create and understand views because it helps you keep track of the intent and stakeholder involved. If unsure simply use "none". The fact that changing the viewpoint, while the view is not empty, "gosts" some element is not a feature or a goal but a side effect: it is not intended to be used when presenting the view, it is only a way to show some discrepencies between what you have modeled and the intended concepts of the viewpoint.

Last, but not least, Archi simply comes with the list of "examples" provided in the specs, but these are that: simply examples (and IMHO not very useful ones). In a real practice, one should use a custom list of viewpoints (BTW, I'm building a solution to define, document and implement this in Archi leveraging some tricks).

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

s_derix

Hi Jean-Baptiste,

Thank you! Your answer made me look into my ArchiMate documentation from CapGemini and it seems I need an update ;-) !! Thank you for pointing this out.

I found this quote:
"A view is what you see, and a viewpoint is where you are looking from"

This quote makes it understandable for me.
(Please let me get this right...)
When I create a view I can then use a viewpoints to look at the view from different perspectives.
Let's say i create a view that shows the claim process, with all business- and application layer elements.
I can then look at this view from the perspective of:
- Application useage viewpoint
- Organisation viewpoint
et cetera.

Jean-Baptiste Sarrodie

Hi,

Quote
I found this quote:
"A view is what you see, and a viewpoint is where you are looking from"

That's only partly true and somewhat misleading...

Quote
When I create a view I can then use a viewpoints to look at the view from different perspectives.
Let's say i create a view that shows the claim process, with all business- and application layer elements.
I can then look at this view from the perspective of:
- Application useage viewpoint
- Organisation viewpoint
et cetera.

No. The viewpoint is not something that you change after having created the view, that's the opposite: you first define the viewpoint and then you create the view. The viewpoints tells you for which stakeholder and for what purpose you are documenting your architecture, so before modelling something you first have to decide it you model it from a business, application, security, data... point of view and if you need few or lots of details.

Read the doc I pointed to, this should makes it clearer.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

DaveVint

Quote from: Jean-Baptiste Sarrodie on March 10, 2021, 13:16:48 PM
(BTW, I'm building a solution to define, document and implement this in Archi leveraging some tricks).
Hi JB,

I was just about to ask if this was possible, so will wait for your solution. In the meantime, I spotted the 'viewpoints.xml' file, along with the various 'vp_*.html' files and their references in plugin.xml. That looks like the viewpoints are fully data-driven. Is that true and could I temporarily tweak those for some custom viewpoints on the understanding that I'll need to maintain this myself until your solution appears?

Cheers,

Dave

Phil Beauvoir

Hi Dave,

you can add your own viewpoint declarations to the XML file but it will only work for that copy of Archi. The identifier of your custom VP will be written to the *.archimate file as well, so it won't work if you share that model.

I have a genuine question. Why do people need to have a tooling mechanism to impose the constraints of viewpoints? Isn't it enough to describe the viewpoint and its concerns and constraints say in the View's documentation field, or in a note? If you are the modeller then you must already know this stuff. If sharing the model then surely the documentation field would suffice? And what if you change your mind?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

Hi,

Quote from: Phil Beauvoir on April 29, 2021, 09:58:38 AM
I have a genuine question. Why do people need to have a tooling mechanism to impose the constraints of viewpoints? Isn't it enough to describe the viewpoint and its concerns and constraints say in the View's documentation field, or in a note? If you are the modeller then you must already know this stuff. If sharing the model then surely the documentation field would suffice? And what if you change your mind?

In its most simple form, the viewpoint is simply a kind of "type" or "tag" set on a view. Associating a restriction on concepts is only a way to avoid people making mistakes, but is not mandatory. In my enterprise setup, we do use a custom viewpoint.xml file so that views are tagged and people (and script) can know the exact intent of the view (but don't setup any restriction).

The view's documentation doesn't address the same need: you use it to describe a particular view instance, but you don't want to describe everytime the underlying stakeholders and concerns addressed, and conventions used.

The viewpoint "tag" is similar to, drives or sustitutes to a legend. In general I would advocate to always put a legend on a view so that people can really understand it, but in some occasion, knowing the viewpoint (and having access to a documented viewpoint library or catalog) is enough.

From a scripting or reporting point of view this is also really needed. For example, I can easily extract a global Data Dictionary by exporting business objects' name and definition used in views tagged as "Business Information Model". Simply exporting all business objects from the model wouldn't work because some business objects are used for a slightly different semantic (maybe with another "specialization name" in the future ;-).

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

DaveVint

Quote from: Phil Beauvoir on April 29, 2021, 09:58:38 AM
Hi Dave,

you can add your own viewpoint declarations to the XML file but it will only work for that copy of Archi. The identifier of your custom VP will be written to the *.archimate file as well, so it won't work if you share that model.
Thanks for the confirmation, understand the limitations.

Quote from: Phil Beauvoir on April 29, 2021, 09:58:38 AM
I have a genuine question. Why do people need to have a tooling mechanism to impose the constraints of viewpoints? Isn't it enough to describe the viewpoint and its concerns and constraints say in the View's documentation field, or in a note? If you are the modeller then you must already know this stuff. If sharing the model then surely the documentation field would suffice? And what if you change your mind?
In my case, I have a team of modellers who need to be consistent, but the membership is dynamic, so it's a basic way to enforce a level of consistency whilst still allowing it to overridden. The specific set of viewpoints we need to support are mandated by an external standard, and are different from the pre-defined ones. We have various templates that are cloned to support new capabilities and new ABBs, so they would have pre-defined views within them with the appropriate configurations.

We don't strictly *need* the tool enforcement, but if the capabilities are there then we may as well use it :)

Cheers,

Dave

tsanov

Hello everyone,

As far as I am concerned, there are two great advantages specific to Archi's "tooling mechanism implementation" as per Phil's question:

QuoteI have a genuine question. Why do people need to have a tooling mechanism to impose the constraints of viewpoints? Isn't it enough to describe the viewpoint and its concerns and constraints say in the View's documentation field, or in a note? If you are the modeller then you must already know this stuff. If sharing the model then surely the documentation field would suffice? And what if you change your mind?

1. "Learning/comprehension aid": in Archi the view points bring user experience which I personally spontaneously associate with a "filter" and to me this is a much better analogy than "the place we are looking from".

2. It's an automation and improves our quality of life. It's like the spell checker in any word processor ...

Nik