Abstraction versus Precision in ArchiMate

We architects love abstraction. Abstraction makes the nitty gritty and complex details disappear. Abstraction makes the unmanageable manageable. Our business colleagues also love it when we produce abstractions. It makes our end products easier to digest. In ArchiMate, you can do both, which means that — apart from the precision-like modeling that you for instance do when building ‘current-state’ descriptive models — you can use the ArchiMate language in a more ‘loose’ setup, e.g. when designing a landscape top-down.

For instance, when designing, if you have a Business Process that requires the services of an application, you generally start with defining that application service in terms of ‘what the business needs’ and then you design how this service will be realized by one or more applications. Or, to stay completely at the busines layer, you define the Business Service you provide to your clients in terms of what your client’s process need and then move down to define what processes are needed to provide that service. In a very simple but fully modeled example:

Here, we have recognized that our clients may want to ask us questions. So, we have defined the ‘Answering’ Business Service that provides these answers. We have decided answers may be asked by phone and by mail and ArchiMate supports that a service is exposed through multiple interfaces, which is useful in a situation like this. In our example, both are Business Interfaces that the client may use if it wants to use the (generic) ‘Answering’ Business Service.

Having concluded we need an ‘answering’ Business Service, we turn to the question how this Business Service is to be Realized and we define two Business Processes that are performed by different roles with different skills. The Call Agent performs the ‘Answer Client Phone Inquiry’ process through the ‘Phone’ Business Interface. Something like it happens on the mail side:

We have one service that is defined top-down from how it is needed. It could be considered a collection of two services realized by two processes, one for answering by mail and one for answering by phone. (If they were not separable as processes, we would have to use an Interaction instead and a Collaboration to perform it instead). If you look bottom-up, the ‘Answer Client Mail Inquiry’ Business Process for instance must Realize its own Business Service (Answering by Mail). A process, after all, is a causally related set of behaviors that is intended to produces something. That is true of the processes in this view too. But we can choose not to model those details.

So, ArchiMate’s definition of a service allows it to be exposed via multiple interfaces:

But its definition of an interface also allows it to expose multiple services. Adding to our example, suppose we have not only an ‘Answering’ service but also an ‘Order Placement’ service, which also is available to our customers via mail (we are a mail order company with a phone help desk).

From a management perspective, it is quite a nice simplification, these two Business Services we provide trough that single ‘Mail’ Business Interface. But a problem lurks here. If we add the processes and roles for both services, we get:

No problem yet. But what happens if we add the roles? We get:

As both roles are exposed via the Mail interface, ArchiMate expects the Composition relation between role and the interface. But that leads to something that my tool (and any other as far as I know) accepts, but that is illegal in ArchiMate itself: two Composite relations to the same child. (To be honest, I think there could be reasons to relax this restriction, as I describe in the book).

Now, I do not show this as a critique on ArchiMate. It is to illustrate that as abstraction always leaves something out, it can lead to problems. There are many such potential problems. It depends on your intended use of a model if you run into one of them. For a relatively small Future-State like ‘broad strokes’ model, it is probably not a problem. For a detailed, used for analyses, Current-State or Project model it is definitely risky. Sooner than later you run into the problem caused by missing information.

ArchiMate has enough freedom to be used to make models with a lot of abstraction, and as such it also supports an approach to Enterprise Architecture design that sees services as abstractions defined top-down (from the needs of those that use the service). In fact, such thinking was an important aspect of the design process of ArchiMate in the first place. But ArchiMate also supports a more specific and precise use that is useful for creating precise ‘current-state’ models. ArchiMate’s its power of expression is good for both.

[Added 19/Jan/2013] Finally, the original design of ArchiMate did not include the Motivation Extension, with its Requirements. If you look at the use of the service concept for design modeling (you have a Business Process and the Application Service describes what is needed for that Business Process which has to be Realized by an Application Function, the abstract use of the service concept) you see that Service is partly used as a Requirement would be used today. In modern ArchiMate, an Application Function can Realize both a Requirement and an Application Service and the latter can Realize Requirements too, e.g. like this:

If I follow the idea that you define an Application Service top-down, as something that follows from the the Process that needs the Application Service, there is overlap with the Requirements concept. But if I put the requirements in that separate object, there is no way I can link those requirements to the source of those requirements, namely the process, other than a weak Association (shown in red). What is missing in ArchiMate is that you should be able to show that the requirements might come from somewhere else in your EA, e.g. from a process.

Some more thought is clearly needed here.