From the Mist

Introduction

This article attempts to reconcile the ArchiMate modelling language with Business-Centred design principles, principles I strongly advocate.

ArchiMate as a language (or, as some would say, a grammar, since a rigid definition of its semantics does not exist) is very “traditional” in the sense that:

• it is very IT-centric
• it explicitly invites the modeller to use a data-centric world view
• it does not exploit the power of distributed systems (for example as it should be doing with microservices)
• it has a very familiar but also frightfully traditional layered structure
• it has never understood the real power of object-orientation

It is my conviction that it is not so much the language that determines the scalability and flexibility of your solutions. But if the language and its usually implicit assumptions about how the world is structured is all you know, it does. So what is important, if you want to reap the benefits of business-centred design and the scalability and flexibility it offers, is to look elsewhere. It is not in the ArchiMate and EA community where you should look, with a very few exceptions (such as Tom Graves and his ilk, usually seen as rogue architects). Maybe we really should expand on the PureArchi idea 😉.

But having adopted this “rogue” world view, not much should prevent you to make models of your solutions using ArchiMate, models that do not distort your axioms too much.

Re-writing ArchiMate

From the standard

This is what the ArchiMate 2.1 standard has to say about Business Models (Chapter 3.2):

The active structure aspect at the business layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships. The active entities are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the concept of business collaboration has been introduced. Business collaborations have been inspired by collaborations as defined in the UML 2.0 standard [7], [10], although the UML collaborations apply to components in the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to the “community” concept as defined in the RM-ODP Enterprise Language [6], as well as to the “interaction point” concept, defined in Amber [11] as the place where interactions occur.

The concept of business interfaces is introduced to explicitly model the (logical or physical) locations or channels where the services that a role offers to the environment can be accessed. The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current business layer modeling approaches to recognize the business interface concept.”

ArchiMate 2.1 specification, (Chapter 3.2)

The business-centred variant

Now the same text, attempted for a different architectural style: the business-centred one, taking advantage from so-called active objects.

The active structure at the business core refers to the dynamic elements of an organisation. The dynamic, active entities in the model are related to entities in the “real” world usually regarded as passive business objects. The active entities in the real world, the subjects that perform behaviour such as business processes or functions (capabilities) are modelled as passive. These are the actors in the real world, such as individual persons (e.g., customers or employees), but also groups of people (organisation units) and resources that have a permanent (or at least long-term) status within the organisations. These are all modelled as passive objects. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on behaviour, which means that the inter-relationships of active entities in the model play an important role. These relations reflect the collaborative behaviour of these entities. Examples are accounts, products, invoices, contracts. This collaborative behaviour is modelled in Business Collaborations.

For architectural descriptions to remain intelligible this strategy pays of when our models scale. Behaviour is related to that active structure element in our model which in the “real” world is that which a subject operates upon or works with. Everything related to responsibilities of subjects in the “real” world is allocated in the model to the active structure elements. For example a carpenter works with wood to create a chair. In the model the chair works with a carpenter to create itself. All behaviour needed to make chairs is allocated to the chair by assigning the chair to this behaviour. This makes our models simpler. A chair can only make chairs. A car can only make cars. An insurance product can only make insurance products. And sell insurance products.

All active structure elements in our models must be requested to perform the behaviour they are assigned to. This request is directed towards their interface. The service may be offered on a number of different interfaces. These interfaces are actively employed by the users (clients) of those interfaces: other active structure elements.

Simplified ArchiMate

In fact the three “columns” of traditional ArchiMate are sometimes too convoluted even for “traditional” architects. We could very well do without the “passive” column, certainly for enterprise architecture. But extended models using the traditional approach often run against a wall for actors and roles performing more and more complex behaviour.

The approach above can do the trick. It is also called the Active-Passive Pattern.