ArchiMate Modeling in Practice: 3 solution model example cases

Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Apr 14, 2013

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

In the previous posting we presented best practices for setting up ArchiMate models using a bottom-up approach. In this posting we will describe three case examples illustrating the added value of solution models. The three cases are: 

  • Rationalize your systems landscape
  • Adding value by supporting projects with architecture
  • Outsource a process 

Rationalize your systems landscape

Suppose that management has “finally seen the light” and has decided that it is time for a major overhaul of the information systems landscape. Recent audits have shown that there is a lot of duplicate functionality, there are many security risks, platforms will be out-of-date soon and worst of all, process owners are complaining non-stop about faulty data. Your task is to map out the baseline situation for planning purposes. Where to start? 

  • After agreeing on scope (what part of the landscape is part of the overhaul), the first thing to do is pull all old documentation you can find. Functional descriptions, infrastructure maps, you name it.
  • In terms of modeling we need to know:
    • Which processes uses which system. Don’t worry too much about mapping out the application services in great detail. A high-level mapping should suffice;
    • Which services from systems are used by other systems;
    • What are the main functions and data objects in the system (“first order functional decomposition”);
    • Which infrastructure services are used, and in which node are they realized?
    • What are the main platforms in each node, and where (location) are they running?


We have found that using this structure you can quickly cover a lot of ground. A small working group does the ground work, and then we ask others (ie. people from operations) to review our work to come up with a more complete model. 

Adding value by supporting projects with architecture

This is a similar issue, but now the focus is not so much on the systems but on the process side of things. We were involved in several engagements where we supported processes with an architecture approach. 

One of the key issues is that the term “project management process” is often interpreted differently by many different players. What does it mean? Where does it start and where does it end?  In practice we often get answers like “That’s obvious! Everyone knows that ….!”. But after comparing the various perspectives and views on the process, it seems that there are more discrepancies than expected. A workshop approach is an excellent tool to get a shared understanding. After that it is usually smooth sailing: 

  • Start with getting agreement on scope as discussed
  • Then figure out what we want to improve in the current situation and how architecture can contribute.
    • Often this can be formulated in terms of (business) services.
    • Example: architecture can help with impact analysis à define a business service called ‘impact analysis’
  • The ‘services’ that are to be used by / in the project management process should be translated to an architecture process.
    • A reference model of the architecture approach (e.g. TOGAF) can help to make this easier
  • Once the process is in place it is time to define:
    • Roles + interactions with the roles in the project management process
    • Deliverables
    • A RACI-chart to indicate accountability etc.

Once the model has been made, one can either have it reviewed, or setup a “role playing” session to enact the process in order to test it.

Outsource a process

The last scenario is more tricky: outsourcing a process entails a lot of changes. We’ve seen some very simple models where the architect simply said: we’ll assign a new actor to the process and be done with it. To really see the impact of outsourcing, a bit more is required. 


As usual – we start by defining scope. What process are we outsourcing? Or, what part of a process are we outsourcing? Not only that, we also need to find out what the relation to remaining processes are. For example: are our processes triggering the process at our new partner? Or are we using a service of our partner in our processes? What does this mean for the flow of our own process: do we have to wait until ‘they’ have completed their work, or can we simply continue? 

Once that is figured out, the next step is to worry about such things as interactions between professionals  access to information systems.


The above diagram illustrates this: here we see the two organizations (modeled as actors), the two processes, interlinked with a business service. So far nothing new. We’ve also represented the fact that the last role in “our” process must somehow interact with the first role in “their” process. Similarly, in our process we have always used an information system. Their information system must interact with ours, so we will need a new interface to our system.

Of course this is just an example, but still: the approach is ‘scalable’ in the sense that such views can be extended one step at a time to cover each of the relevant aspects.

By using different models in the same repository that are interlinked, your models will be much more valuable. With advanced reporting capabilities in Enterprise Studio, any user with a web browser can get access to your models. Read more on setting up a model repository in our next post, so as always: Stay tuned!



Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus