Automating Business Services in ArchiMate

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.


8 thoughts on “Automating Business Services in ArchiMate

  1. Your issue is that you are attempting to use a single business service to represent both the automated and human customer support service. I would recommend creating a human customer support service (realised by the customer support process), and an automated customer support service (realised by the automatable customer support process). You can then compose (with the composition relationship, and visualised with nesting) the two business services into a single Customer Support business service.

    The reason you must in fact use two different business services is that different behaviour is observed by the customer at the phone and web interfaces. Thus, different business services must be modelled.


    First of all, thank you for your time and comment.

    Based on your comment I assume you agree with my use of the assignment relationship linking application layer active structure to business layer behaviour.

    I do not know if I fully agree with your suggestion to create two business services.
    First, a lot of literature uses services like this, take for instance Tom Graves book “Doing Enterprise Architecture” (I warmly suggest Tom’s books by the way, see Most of them point to the logical/physical relationship between the service and the realizing (active) structure(s) as the advantage: you can manage a whole list of realizations as one, from the point of view of the service.

    In this light I often hesitate to create a one-to-one relation between interface and service: a new service definition for a new interface or vice versa. I fear that if you create a new service each time the consumer has a different (material) experience, you end up in this one-to-one world.

    I tend to define services based on the “need” of the consumer and use interfaces to model how the consumer interacts with the actual realization to serve the consumer’s “need”.

  3. Indeed. However what if we were to specialise the customer support need to “Simple Customer Support” and “Enhanced Customer Support”? As you stated, the automated option provides only rudimentry answers, and thus is not suitable to the needs of all customers. So in my view there are indeed two business services at play here, each addressing a different (although similar) customer need.

    Here’s some food for thought…

    Let’s say we have a business process that involves a person taking a piece of paper and folding it in half. Let’s then say we have five people in a line following the same process. Each person takes the piece of paper from the previous person, folds the paper in half and hands it to the next person.

    In this scenario we actually have three processes because the people at the beginning and end of the line need to follow slightly different steps. So the three people in the middle are following the same process right?

    So how do we model this? We can’t model three processes with the middle process looping back on itself. We would have lost the fact in the behavioural model that there are five steps to our broader process.

    This scenario has led us to consider the fact that architecture deals with instances more than it does types. The three processes in the middle are of the same type, but there are three instances of that process running. Thus, we need to model all three of those processes in our model – each of the same type. Unfortunately ArchiMate doesn’t provide a means of us expressing that they are all of the same type.

    The same is true in building architecture. We may have a building with a number of beams meeting the same specification. We don’t however in our architecture simply have a single representation for the single beam type. We have a representation for each beam in the house. Without this, a builder wouldn’t know how the build the house.

    So back to your example…

    If our customer support process is in fact a process instance (rather than a type), then it can only be realised in a single way in the real world. If we were to have the exact same process performed both by a human and by a computer, then we would have two process instances (albeit of the same type).

    We could however consider a single process instance being jointly executed by a human and a computer. Thus in this case we would have a single implementation for the process, which involved BOTH a human and a computer.

    So we can see either way that a single process (instance) must have only a single implementation in an architecture model.

    Now, a business service represents the externally visible behaviour of a business process (or business function). Thus, the instancing issue extends also to business services. If we have two different processes realising a single business service, then my view is that this means that both services JOINTLY realise the business service. They dont each independently realise the business service in its entirety.

    The point you make regarding having multiple possible implementations for a single service is true when considering only types (not instances) because the implementation hasn’t yet been decided. In an architecture however you are laying out the plan for the implementation such that it can be built. The architecture cannot leave open to interpretation which implementation is to be selected. The architecture must specify that selection.

    So it is valid to assign multiple interfaces to a single service as long as those interfaces access the same process implementation – that is the implementation that realises the assigned business service.

    Please don’t take anything I say here as gospel. I’m actually really hoping to open this up to further discussion and am very interested in getting your thoughts on the above.


  4. Here’s my point of view:
    I agree with Bill that it should be 2 different services. Just because you say: “whose questions are just too complicated and require a customer support representative.” which in fact means you deliver 2 different kind of services. The fact that the support person is involved has added value on top of what the application service offers.
    Now suppose the support person does not offer any added value meaning does not ask questions to get more information from the customer, does not give any hints towards a solution, does not do any interpretation of what the customer says in fact he/she just friendly listens to the customers and enters exactly what the customer says into the tool. Then I would model it in a different way (I’ll send you a figure of my model, because I cannot add it here).
    Now you indeed have a loop in there: you have a process realizing a service and that process uses the same service. Which I think is always the case, any process can realize a certain service by just calling on ‘something else’ realizing the same service. I modeled the used by relation between ‘customer support service’ and ‘customer support process’ for clarity, but I think it can actually be omitted.

    [Blog Editor’s Note 04/10/2010: the figure mentioned can be found at]

  5. Thank you both (Bill and Wim) for the insightful comments you made. I updated the original post to make sure people don’t forget to read them as well.

    These comments have given me much food for thought and I’ll try to make some follow up posts.

  6. @Bill: I don’t fully agree with your view. On the example of folding a paper you say: “We canโ€™t model three processes with the middle process looping back on itself. We would have lost the fact in the behavioural model that there are five steps to our broader process.” In fact I would do exactly that. I don’t think an archimate model intents to clarify that kind of detail. That would become clear when you would model the global process of folding a paper 5 times (eg. in BPMN). In my view we would never talk about instances in an archimate model, as such I would also say that if 2 processes realize a business service they each independently realize it.

    I agree that an architecture cannot leave room for interpretation, but I’m sure an architecture would not only consist of an archimate model. Just like you don’t create a design by just creating classdiagrams. You also need the dynamic behaviour (BPMN, sequence diagrams,…) which you cannot model in Archimate. BTW: I think the ‘triggering’ relation is an attempt to make it possible to model both structural and dynamic behaviour in 1 model, but it clearly is not enough to clarify all implementation choices.

    Nevertheless, as I mentioned in my previous post, I agree that in the original question there should be 2 services because they are distinct in this case.

  7. @wimdrossaert: Let’s say you have five warehouses in a supply chain you need to model. Let’s also say that the processes for receiving and forwarding goods are standardised. Let’s also say we model five Actors – one for each warehouse organisation.

    In my view, we also need five processes – one triggering the next. It is your assertion however that only a single process should be modelled – looping back on itself. However from a process optimisation standpoint (value stream mapping, etc), it doesn’t speak to what is actually going on in my view. Looking at any one warehouse in the model would give the impression that the warehouse independently performs a process that loops back on itself.

    If five processes are modelled, the model shows that the five warehouses are related within a chain of processes. If only a single process is modelled, we see five warehouses independently executing the same looping process.

    Let’s now say each warehouse uses a warehouse management system. Each warehouse has the same system deployed within each warehouse. Each system stores its data independently from the other systems, but the data structure is standardised. There is a file transfer that moves between warehouses to tell the next receiving warehouse about the goods it is receiving from the previous warehouse.

    Now, do we model a single application component or five application components? Again, it is my view that we need five application components. In my view, each is a different logical application component. Each stores different data at different times. Each serves different regions. Even though they are all of the same type (i.e. a standardised application), they are different logical application components. Each serves a different purpose in the architecture.

    If in our architectures we only ever deal with types, then it is unclear as to how the enterprise is to be instantiated (i.e. built). Even UML, we have the Object Diagram which shows how classes are arranged in actual instances and how those instances interact. Why do we not need any such construct in ArchiMate?


  8. @Bill I think our views are not as far apart as it looks ๐Ÿ™‚ I agree about the distinction between types and instances and I also agree that somewhere in the architecture these instances need to be clarified. Where are views differ: I would not model this in archimate. I would use archimate to model the structure of types. I would use other diagrams to model instances just as I would use other diagrams to model behaviour. But that might just as well come from the fact that I’m merely getting started with Archimate ๐Ÿ™‚

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.