This is the second posting in our series on using ArchiMate in practice. The goal of this posting is to come to grips with the term “architecture model” and relate that to the use of ArchiMate. This is a tricky discussion: despite many definitions, it appears that architecture is still an elusive term:
• It has to do with granularity, we distinguish between “architecture” and (detailed) design
• It has a process aspect (i.e., “doing” architecture) as well as a product aspect (i.e., the architecture that we can stick on the wall with Blu-Tack.
• It has a timing aspect: the architecture of ‘now’ versus the architecture of ‘tomorrow’
We will use a bit of theory to explain our view on this discussion, starting off with the definition of architecture from the ISO/IEC/IEEE 42010 standard.
Definition of architecture
The ISO/IEC/IEEE 42010 standard defines architecture as follows:
The Architecture (of a system) is the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
In other words, this definition says that:
• Architects see the world in terms of systems (in the broadest possible meaning of the word: value chains, organizations, information systems, etc.)
• To understand the architecture of a system, we must find out (a) what the fundamental concepts or properties of that system are, and (b) what the principles underlying this fundamental organization are?
This is still fairly abstract. We will use the FRISCO framework – which, regrettably, was never published formally but still managed to make its way in the original book on ArchiMate – to drill down and show what this means in practice.
The process starts when the architect observes / perceives the real world, often called the universe of discourse. This is pure ‘sensory input’. Through the process of “conceiving” or “sense making”, the architect gets a mental picture of what is going on in this universe. Typically we are not interested in everything. There is (or: should be) come focus. In FRISCO, the concept of a “model” is therefore defined as:
a purposely abstracted domain of some ‘part’ or ‘aspect’ of the universe a viewer may have an interest in
In other words, through purposeful abstraction, we arrive at a (mental) model of the universe under consideration. This is the first level of subjectivity: not everyone is interested in the same phenomena, and therefore will arrive at different abstractions.
To continue the process: we now ask the question: how is the system organized? This is a mental process that works on the model. Finally, we have to answer the two basic questions: what is fundamental about this organization, and what are the principles underlying it? This is the second level of subjectivity: what is fundamental to one person, may not be fundamental to another. It all depends on one’s background, concerns, interests, and so on.
Note that most of this is a mental process. If we want to communicate about models, or architectures, we have to make them explicit in some form or shape. The act of representing a model formally leads to a model representation. In practice, we do not distinguish between a mental model and the represented model that can be mounted on the wall as a nicely colored (big, wall-sized) poster.
Building on this, we should accept the fact that “doing architecture” is mainly a communications game: we have to build a shared understanding of what is essential about the way a system is organized. This requires a shared vocabulary and framework for analysis.
In practice we see that this is often lacking, despite the growing popularity of ArchiMate. There still is a lot of confusion and different interpretation of key concepts such as service, process, and system. Also, we still see a lot of architects worrying about implementation or construction details, rather than looking at the bigger picture. For example, we see a lot of discussions about how system X is linked to system Y, or how process A influences process B. A much more interesting question from an architecture perspective is to move away from the “instance” level and worry about the “patterns”: how do we want our systems to be interlinked? How do we want our processes to interact?
This is where ArchiMate comes in. As we will see in the next few postings, ArchiMate was designed specifically with this “big picture” in mind. It offers a set of well-defined concepts and relations that allow architects and other stakeholders to reason about architectures. It is recommended to use other languages (such as ERD for data, BPMN for process, TDM for decisions / rules, and UML for software) for more detailed designs.
Conclusion & Outlook
In the next posting we will dive into the foundations of the ArchiMate framework. If you have any questions or suggestions: feel free to drop us a note! Stay tuned!