The topic of “abstract” vs “concrete” architecture seems increasingly popular, especially in relation to the ArchiMate language. Recently this topic came up in consulting assignments, teaching settings, and the linkedIn group for ArchiMate. In a previous posting I briefly touched upon this topic when I wrote about the combining the specialization relation and the aggregation relation to create a plug-and-play process architecture. In this posting I will re-examine this topic. The proposed solution has been tried and tested and is now used in several organizations.
The issue to be solved is fairly straight forward. In architecture modeling, two approaches can be followed: (a) an architecture model is very close to the physical world and attempts to represent all the `things’ in it one-on-one, albeit at a high level of abstraction, or (b) an architecture model abstracts from reality as much as possible and only represents `patterns’ of (interactions between) `things’ in the real world. The former is frequently referred to as a conceptual or abstract architecture, whereas the latter is often referred to as a physical or concrete architecture.
Many architecture approaches, including e.g. Capgemini’s Integrated Architecture Framework and TOGAF distinguish between conceptual, logical, and physical architectures. Conceptual and logical are abstract, whereas the physical architecture is concrete. The ArchiMate language does not distinguish between these levels, even though it is often claimed that behavioral concepts (services, functions, processes) are abstract and active structure elements (actors, roles, application components) are concrete.
Both abstract and concrete architecture models can be very useful and the question is how to combine them in a single model to get the best of both worlds. The underlying assumption is that ArchiMate – an open industry standard – language is used.
The basic observation underlying the solution proposed in this blog post is this: at the abstract level we identify the type of things we wish to talk about, whereas in at the concrete level, we identify their manifestations in the real world. For example, at the abstract level we want to talk about ERP software that supports people in performing their work. At the physical level, however, we want to talk about the fact that location A uses an ERP implementation from one vendor, whereas location B uses an ERP implementation from a different vendor, for performing the same kind of tasks (i.e., in a similar process).
The ArchiMate relation that is closest in semantics is the specialization relation which can is defined formally as “The specialization relationship indicates that an object is a specialization of another object”. This relation is mostly used for type/instance relations and is well known in many langauges including UML, Object Role Modeling etc. In this case we use it to denote that an abstract model element may have different concrete manifestations.
Example 1: component types and instantiations
The first example diagram illustrates the situation outlined in the previous section. At the abstract level, life is relatively simple; all that is to be modeled is the fact that for the process named Hotel reservation (be it at the front desk, or online) uses two application services that are realized by an ERP component:
A big advantage of this approach is the fact that the specialized (concrete/ installed) versions of the ERP package inherit all aspects of the abstract ERP component. I.e., the two application services are inherited and need not be modeled again. Similarly, use of infrastructure services, access to data etc. is all modeled only once. This allows one to create an Amsterdam-specific image which could look something along the lines of:
Example 2: domesticated applications
Another interesting example of this mechanism showed up when discussing the use of the domestication (thanks for sharing this Ronald, Magchiel !).
The example case starts with the definition of a domesticated application. This was defined by the group as an application that uses federated authentication services as well as group service using some standards (modeled using the principle concept in BiZZdesign architect). It was recognized that domesticated applications can be accessed (suggesting the Application Interface concept) using OpenSocialGadgets. These gadgets are used in a portal environment that is called EduSocialPortal. The abstract architecture therefore can be modeled as follows:
The specialization concept is a powerful one and can allows for a straight forward way of modeling at two levels of abstraction. As is so often the case: this comes at a cost as both levels as well as the links between them have to be managed and kept up to date. Even more, when generating views in an architecture tool, the modeler should be very aware that concepts of two levels of abstraction may be combined in a single view. I highly recommend adding a profile (i.e., “stereo typing”) concepts from the conceptual layer so that they can be easily recognized using a color-view.