02/10/2010: after posting this, there were some insightful comments made. I encourage you to read them as well.
I am generally very enthousiastic about ArchiMate. What is not to like? It produces elegant models that are easily understood by a broad family of stakeholders and the viewpoint categorization is refreshing and very useful, especially compared to for instance TOGAF 9. It’s not all sunshine however, there are for instance a couple of points in ArchiMate where I tend to differ in opinion with some fellow architects.
One of those points are the assignment relations between the application layer and the business layer as shown, using bold red, in the following subset of the ArchiMate 1.0 metamodel.
Before I go any further I have to state this disclaimer: I will explain my point of view given my current understanding of and experience with ArchiMate. If you have any remarks, negative of positive, on the reasoning presented in this post, I would appreciate if you would post a comment or contact me directly!
Metamodel (click to enlarge)
According to the specification (see Chapter 7 “Cross-Layer Dependencies”) these relationships have the following meaning:
Assignment relationships, between application component and the different types of business behavior elements, and between application interface and business service, to indicate that, for example, business processes or business services are completely automated.
In short, in case of complete automation, you assign active structure from the application layer to the business behaviour instead of the, usual, active structure of the business layer (actor and role). With this active structure from the application layer, an application component, comes the external structure, an application interface. The application interface will be the interface through which clients use the business service.
Let’s develop a small and simple example where we use these relations, explore their meaning and identify potential pitfalls.
A company offers a customer support service to their customers, this service, “Customer Support Service”, is realized by a business process “Customer Support Process”. This process is executed by the customer support department who offers a phone interface for customers. The process itself is fairly simple, first the support request is analysed, then a knowledge base is searched to find possible answers, the possible answers are combined into a support answer for the customer.
As you can read in the process description, the actors in the customer support department use a Knowledge Base application. They access it through a web interface. This application offers a service where you can browse and search common problems and their resolution. The customer is not directly exposed to this Knowledge Base application. The model belows shows these elements and their relationships.
Example #1 (click to enlarge)
We haven’t yet used the assignment relations between the active structure of the application layer and the behaviour of the business layer.One way to introduce them is to simply state that instead of offering this service using the customer support department, it is completely automated with direct access to the Knowledge Base application. The Knowledge Base application is capable of performing a simplified version of the Customer Support Process and the customer directly accesses the web interface. The business process has to be simplified before it can be completely automated. Our Knowledge Base application is not, as most applications aren’t, capable of intelligent analysis of the support request or possible resolutions.
Example #2 (click to enlarge)
The above simplified situation, with only a completely automated realization of the business service, is not very common. In most cases the customer can use both interfaces. The Phone interface is offered for customers who are unable or unwilling to use the web interface or whose questions are just too complicated and require a customer support representative. The web interface is offered in case the customer has access to the Internet and is able and willing to use the direct web interface. At first sight we can simply model this as seen below.
Example #3 (click to enlarge)
But is this correct? We have an application component whose internal behaviour is represented by a business process, it completely automates the business process, But this process behaviour itself uses an application service that is realized by … this very same application component! That sounds pretty much like an endless loop. I don’t think it is impossible as such, depending on the level abstraction level of the process definition or the level of composition of the application component, you could defend the above model. But honestly, I feel it would barely represent reality.
It is clear that we want to avoid having a business process that uses an application service that is implemented by an application that itself completely automates that business process. Yet, the situation with two interfaces to a knowledge base, one offering access through a customer support representative and one offering direct access to the application, is very common. Both interfaces support the same buFsiness service, they both fulfill the same customer need. We can’t use a single definition of internal behaviour though, so let’s update our example and define an extra business process. This new process is a simplified version of the original process that only allows simple questions and is therefore easily automatable. This new situation is shown in the diagram below.
Example #4 (click to enlarge)
The above example has been kept as simple as possible. In practice it would be unlikely that the original web interface of the knowledge base application would be considered usuable by customers. In most situations you will find a new application that offers a more suitable interface for end users, this application will use the original knowledge base application through an application-to-application interface (this interface is not shown on the model).
Example #5 (click to enlarge)
These simple examples show my current understanding of these particular relations in ArchiMate. If my understanding would be incomplete or even flawed, I hope to find constructive comments to enlighten me.