ArchiMate Modeling in Practice. Top-down: Business architecture models


Subscribe
Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Feb 27, 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 explained two strategies for getting started with ArchiMate modeling: top-down and bottom-up. Over-simplifying, we suggested to use “inventory style” models (to catalog the ‘things we have / do’) and then figuring out the relations between them. There’s usually a lot of information that can be (re)used. Also, the ideal approach is using a workshop setting.  

This leaves an important question, though: what type of ‘things’ should we catalog? As always, the answer is: it depends! Without consideration for the specific circumstances of your organization, a first stab might be: 

  • Products and services
  • Business functions or capabilities
  • Process map
  • Logical application components
  • Information / Data decomposition
  • Logical infrastructure components 

This is quite a list so we will not cover everything in detail here.  In this blog posting, we will cover the items in the business architecture domain, and in the next posting we will continue with the items in the application / infrastructure domain. We will give a high-level overview of an approach for each of the items: how to do it, who to talk to, where to find the right information. 

Before we dive in, some general remarks: 

  • The trick to be successful with building up the top-down (homogeneous), high-level models is to avoid going in to much detail
  • Especially for the baseline situation, a lot is already ‘known’ and ‘in the heads of people’. There is usually also quite a bit of debate on how to structure models, definitions, scope, etcetera. We advocate a workshop-based approach to facilitate knowledge sharing and getting a shared understanding. This works best in a small team with expertise from various domains
  • Typically reference models help. E.g. for telco’s TAM/eTOM/SID, or BIAN for banks
  • Also make sure to use a two-pronged approach: one group creates the models, the other is “devil’s advocate” and challenge the results and assumptions in them.

Products and services

One of the first things to do is to build a model of the products and services that an organization offers. This may sound trivial, but often that is harder than it seems. The main problem that we often see is: are we going to model the product/ service types (‘gardening product’) or all the instances (pitch fork, shovel, mower, etc.)?

Another issue that we often see is around re-use of generic services – which is illustrated by the diagram below. Take for example a payment service. Too often we see arguments such as “we will model two payment services because they are handled by two different departments”. Or “we will model two because they are offered through different channels”. Well, that maybe true but that doesn’t change the fact that they are functionally the same! The fact that they are realized more than once, or offered through more than one channel does not change that fact!

 ArchiMate_2.2_Products_and_services_model

 

ArchiMate_2.2_tip
TipGo talk to your strategy department, they probably have some good insights in your product architecture (both as-is, and to-be!).

Business function map

The business function map is – in our option – extremely useful. Sometimes this is equated to a “capability map”. There is a difference between function and capability, but indeed, the business function concept can be used to model capabilities. 

Remember, loosely defined a business function is used to model behavior without (a) ordering, and (b) specifying how / in what order the behavior will be executed. A good place to start is by looking at Porter’s value chain model (wikipedia). Here too we see (primary / secondary) functions. The well-known diagram from the original work, translated to ArchiMate could look like this:

ArchiMate_2.2_business_function_map

There’s also a risk in taking the value chain model as a starting point: unfortunately we have seen architects argue “this model does not apply to us, we are an information company so we do not have logistics”. While that may be true, the trick is to ask yourself the question: what is it that you do?

Another good starting point is the use of a reference model. In many branches we see ready-made reference models that can be purchased (or even downloaded for free). The SID/TAM/eTOM reference models are a good example. Simply import the reference model in your modeling tool (preferably BiZZdesign Architect) and go over the model elements one at a time: do we have this? Is it named differently? You will probably end up with something like this:

 ArchiMate_2.2_Reference_model

The diagram shows a good deal of overlap between the two models. However, both the reference model and your own model might have areas (highlighted in orange) that do not match.

ArchiMate_2.2_tipTipDo not reinvent the wheel: reuse what is out there. Use reference models and group workshops to figure out your business function model. Don’t fall in the trap of copying your org chart.

Process map

Coming up with a good process map is far from easy. We typically see an approach where processes are defined per department. This is far from useful. 

We typically try to model our processes in an “end-to-end” or “from customer to customer” manner. That is, start with a request from the customer, and find out what processes are used to fulfill that request.  Typically such processes span many business functions and/or departments. The above diagram illustrates this. We have “chained” functions to come up with the end-to-end processes. Note that the process starts and ends with a service that is used by a customer (role).

ArchiMate_2.2_Process_map

ArchiMate_2.2_tipTip: Start with the customer . You already developed a product / service architecture (you didn’t skip that, did you?) so re-use what you have there. Develop the process map by ‘chaining’ functions.

Conclusion

In this post we discussed using a top-down approach for setting up enterprise models, and shared some of our tips and best practices that we’ve developed over the last few years. In the next posting we will continue this and present some examples from the application / infrastructure domain. Stay tuned!

Delivering Business Outcome with TOGAF and ArchiMate

SUBSCRIBE TO BIZZDESIGN'S BLOG

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