Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
In this series, we have discussed various aspects of the ArchiMate modeling language using a “first principles” approach. We have covered structure vs. behavior, the three layers, (with internal / external aspects), the use of specialization, and so on. A key issue that we have often discussed is the distinction between the (mental) model of the modeler (i.e. the architect) and the visualizations that he or she creates for stakeholders in the organization. In this posting we will elaborate on that aspect.
In posting 2 we have discussed the fundamentals of the mental process of the modeler. Simply put, we observe the world and discover concepts and relations about the domain under consideration through a process of sense-making and abstraction. We use a language (in our case: ArchiMate) to represent this model, preferably in a 1:1 manner. That is, it would be useful if each concept or relation in our mental model maps to one ‘box’ or ‘line’ in an ArchiMate visualization. These ArchiMate models can become huge. We have seen models with more than 10,000 model elements.
What to show, how to show it
Rarely do we find someone who is interested in every single aspect of a model at all times. Rather, we select only the relevant part of the model, based on the context and the stakeholder who we want to communicate with. Thhen we choose a particular type of visualization that matches the needs and style of this stakeholder. The following diagram illustrates this:
Here we see how a modeler perceives part of the real world under consideration to form a mental model. This mental model may be represented as an ArchiMate model. In a given context, the modeler may analyze the communication preferences of a stakeholder, select a part of the mental model (indicated by a box with the dotted line), and create an appropriate visualization based on this selection. This is a complex (mental) process that requires a solid understanding of the domain in terms of concepts and relations as well as about communication styles, psychology, visualization styles etcetera.
Formalizing the terminology: views and viewpoints
ArchiMate supports this process through the views and viewpoints mechanism, which is borrowed from the ISO/IEC/IEEE 42010 standard. Formally these concepts are defined as follows:
A representation of a whole system from the perspective of a related set of concerns
A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
More simply put: a view specifies what you see when considering a system from a specific perspective, whereas a viewpoint specifies how to create such a view. In practice we are quite used to using viewpoints. For example, a bookkeeper uses a fixed set of (notational) conventions for creating financial views such as a balance sheet. Also, an electrical engineer or a building architect use a fixed set of symbols and style of visualization for crafting blueprints. This is not a new mechanism.
Views & communication
One of the pitfalls for many architects is to model too much. We see a trend that architects typically include too much detail in their models. Another pitfall is to show too much on views for our stakeholders. The fact that most tools make it so easy to craft amazing views may be a double-edged blade. Hence our advice: model as little as possible, but not less! Crafting views for specific stakeholders is a process that should not be taken lightly. Yes, it costs time to create the perfect view, but this time is very well spent if it helps in making that big billion dollar decision.
Moreover, be aware that not all stakeholders have the same visual orientation that architects tend to have. For example, people with a background in law are more used to text, and those in finance may prefer spreadsheets or charts. Furthermore, many stakeholders are less interested in the architecture itself than in its implications. Diagrams are therefore not always the most appropriate means of conveying information. Other types of views such as text, tables, or matrices may be more useful.
Conclusion & outlook
The next posting will conclude this series. Having covered the fundamentals of ArchiMate, we will then discuss some of the language and philosophical issues in using the language in practice. In the meantime, if you have a question or suggestions, please drop us a note!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: