When looking at ArchiMate diagrams its easy to miss the fact they are part of a model, and not just pictures. This blog addresses the difference and demonstrates some basics around models.
Last week someone was commenting one of the views I demonstrated in a blog, and pointed out something that didn’t make full sense in the diagram but had been addressed in the view documentation. Its very easy to forget that we are not talking about pictures when we speak of ArchiMate models. In the blog my ArchiMate views are just images. I wanted to show some practical examples and discuss this. For anyone that doesn’t actually do modelling using a modelling tool, but interacts with those of us that do, this blog is for you.
Before I get started its worth mentioning that a view and a viewpoint of architecture is a concept that extends beyond the modelling language. We tend to talk about views visually, but the view taken from a specific viewpoint could expressed in writing if we wished it to be, but you would miss the benefits of modelling elements and relationships with a tool.
The dictionary definition of a diagram is:
“a graphic design that explains rather than represents especially: a drawing that shows arrangement and relations (as of parts)”
Of course there are many dictionaries but they all follow a similar pattern.Technically Figure 1, is both a view and a diagram. On this website its a diagram, which is a representation of an architecture view. the actual full architecture view has a lot more information in that is represented in figure 1.
Of course we can just use something like Paint or Visio to create a view like above – and it has a lot of value, but in those tools are for visual representation, and not modelling.
I previously addressed Documenting An Architecture Model – but I wanted to give a more complete example in a modelling tool.
Figure 1 is a fairly self explanatory made up view which gives a level of information by itself. But it doesn’t tell us everything. I will show some of the things that differentiate pictures and diagrams from an architecture view in the rest of this blog.
The first thing to show is that views can have their own documentation – Figure 2 shows this – I have selected a view and you can see its documentation in the field below.
Of course if this was a real view I might also have provided links in the documentation to the organization chart. Although the view documentation is short here, it helps set the context for the view, and does provide some valuable information.
Individual elements or relationships can also be documented:
As well as elements having documentation relationships can:
The relationship type gives you an understanding of what kind of relationship the elements have but it doesn’t tell you why. That’s something I will typically do in documentation. This is particularly important when it comes to documenting less defined relationships, such as associations.
The point I am making is just looking at the diagram does not give you a complete picture. Some tools will allow you to auto generate documentation:
Many tools allow you to connect all kinds of metadata to elements & relationships, and allow varying degrees of customization in the example below you can see a references link I added:
Its very tempting to add lots of metadata to a model because you can, but i tend to think carefully about the value of any kind of information I would want to maintain.
Some tools such as Enterprise Studio, allow some pretty advanced analytics depending on the information you store with the model.
Navigating the model
The main thing that sets a modelling tool apart from a visual tool like PowerPoint and Visio is the fact its a modelling tool. We can navigate each element and see its relationships and the different views it appears in. The tool stores the elements and relationships as a fully relational model
Auto generating views
Lets say for example a stakeholder came to me and asked me to tell them a little bit more about what an enterprise architect is – With some tools I can automatically generate views. Take a look at a view I generated literally in 5 seconds:
In previous blogs I have used the enterprise architect role, and because the modelling software knows all the roles and relationships between each element in a model, and the rules for modelling in archimate we can very quickly create something meaningful.
The more work we do with our models, the more value they can bring us.
An architecture view is a view into a model. Figure 9 shows our auto generated view but on the left hand side you can see in the model browser that our model package contains many elements that are not on this view (because we created this view to only show actor cooperation’s to the enterprise architect element)
The model package contains many elements, views, and relationships. You see them on the model browser. You could theoretically take all those elements and put them onto a view:
Theres too much to remain readable on a normal screen – and it doesn’t make sense to show our architecture in a single view. This is why we break down architecture into multiple views, created for people interested in its different aspects.
To put in simple then. a view is just a small part of a model we are communicating, As you can see, the view in Figure 1, would be part of something much bigger.
So we can see that models have lots of elements and relationships, and different people have needs to see different things. View Points define which parts of an architecture we look at. A viewpoint definition tells us which types of elements we are interested in, and which types of relationships are allowed between them. There are many standard viewpoints defined in places like TOGAF and the Archimate Manual.
Figure 8 was an automatically generated Actor Cooperation View. It was generated from a Archimate 2.1 Viewpoint. The viewpoint definition tells exactly what elements and relationships are allowed within the view, so our tool could find those within the model and generate a view from the viewpoint definition.
As your models become well developed benefits start to come from automatically derived relationships. Not every relationship we use is created by hand. You can find more information on them in the Archimate Manual
Summing It Up
As your model grows the value we can gain from it also grows. For a model to realize its full potential requires architects to actually use it, have competency around it and have a level of discipline. When we achieve that modelling can be used to save time in understanding your enterprise and understanding the impact of change across the different IT aspects. At this point it can become an invaluable tool for management.