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
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!
Tip: Go 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:
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:
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.
Tip: Do 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.
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).
Tip: 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.
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!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: