- Adaptive Enterprise
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.
So I got my ArchiMate® certification… now what? Does that sound familiar at all? We see a lot of organizations and professionals struggle with the questions on how to get started with their enterprise architecture models. This makes sense: there’s an overwhelming amount of practical guidance (often piecemeal, though) available online, the pressure might be on (there is a lot of places where we expect ArchiMate models to add value) and the company has just invested in training and tooling (Check out our flagship software, BiZZdesign Architect).
Our goal with this posting is to present two distinctly different approaches to getting started with your modeling activities. Be warned, that both adhere to the “model as little as possible” adage: we strongly believe that:
(a) you should only model what you intend to maintain
(b) you should stay away from (construction / implementation) details as much as possible
Further, note that the two strategies are not mutually exclusive. The point is to build up a knowledge base that can be re-used so eventually you’ll end up with a “complete” picture of the enterprise.
For many organizations there is a big need to use models in an ‘inventory’ style: building up a catalog of assets that we have, and figuring out how they are related. These models can be a big help, for example in making investment decisions, or figuring out the impact of a proposed change.
The big advantage of this strategy is that it is / should be fairly easy to get started. Usually there are list of departments, systems (we have to pay for them, after all), and processes that we can use as input. Here are some practical tips to get started:
Once you have these “top-level” models, then next step is to create relations between them. This will be more work and will require diving into the “in between concepts”. For example, if you identify that a process is supported by an application, then try to figure out the application service that sits between these two first. An easy way to do this is – again – to use workshops. Using the applications / processes situation as an example:
Note, by the way, that ArchiMate can be extended to capture other (qualitative / quantitative) information about your applications, processes etcetera. For example, we may want to capture functional / technical quality of your applications, annual costs, or size in function points. With our tools you can then visualize different aspects of your model to support decision making.
The second approach is completely different from the first. Rather than cataloging “everything we have”, we take a single ‘thing’ (process, system, department) and build a layered picture of everything that connects to it. Two examples:
Below is an example from an actual assignment in which we used this process (over and over, one application at a time, until we covered them all):
This process is actually easier than it sounds even though it does require a stable factor: the person in charge of the modeling should always be the same, in order to maintain some level of consistency. Here, again, we typically follow a workshop approach:
So: which strategy should you adopt? The funny thing is: it’s not an either/or question! We usually do both, at the same time, but at different speeds: the top-down approach is something that can typically be planned. 2-4 weeks for business functions, 2-4 weeks for applications, and so on. The bottom-up approach lends itself better for a “start when there is a need for it” approach: we’re about to embark on a project to upgrade a process/ system and we need to know more about it – an ideal situation for getting our hands dirty!
The above diagram illustrates the challenge for architects in this light. If you want to know more, then stay tuned: in the next posting we will cover the practicalities of setting up a repository for your models and assignment roles and responsibilities.