Abstract and concrete architectures

Introduction

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

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 solution

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:

At the physical level, we wish to denote that two ERP implementations exist and that branch offices (modeled using the Actor concept, see e.g., this posting) uses these different implementations. The following figure shows how this can be represented:

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:

Note that this mechanism should not be used to represent that we have two ERP packages by two different vendor platforms. Vendor platforms, such as SAP or PeopleSoft are usually modeled using the System Software concept.

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:

Again, the specialization mechanism is used to cross the bridge to the more concrete/physical level. Specific domesticated applications (i.e., Alfresco) deliver services (document management) that can be accessed via gadgets and are made available in a specific EduSocialPortal (Coin demo portal):

Again, the inheritance mechanism ensures that the proper application functions with underlying infrastructure services are used.

Final remarks

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.