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:
Use workshops but collect data first: usually there’s a lot of information out there already. Collect as much data as you can, even if you know it is outdated. Distribute this to workshop participants and use short, focused sessions to develop your model
Worry about ownership: who will be accountable / responsible for maintaining the model once you’ve created it?
Focus as much as possible on a single concept or set of concepts. For example, focus on a ‘product architecture’ (with products, services, and contracts), a business function model, or an application landscape
Don’t worry too much about relations between your inventories yet. If you discover relations between e.g. your applications: model them. If you discover relations between your application components and business functions: keep a list and model them later
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:
Make sure all participants have reviewed all materials that you’ve created so far
Generate or build a matrix with applications in the rows, and processes in the columns
Work your way through the matrix column by column. First indicate with a check-mark (if you do this “old school” with pen and paper: use a sticky note!) to indicate that an application supports a process
Once completed, try to make out the application services. Eliminate duplicates as much as possible
When done, update your model in a tool and create views for visual inspection by process owners and system owners (both!).
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:
Start with a business process: ask yourself in this process is part of a bigger “end-to-end” process and map out the services that this process realizes. Map out how they are used by customers in different roles. Then drill down into the IT landscape: which application services are required to make the process work? Which systems deliver these services? Which infrastructure services are required? Which nodes (with platforms / hardware) are required to make the applications work?
Start with an application component: start with a functional decomposition: what are the main functions and data objects of the component? What are the services (of other applications, or supporting infrastructure) are required to make the application work? Which services are realized, and used by other applications or business processes?
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:
Try to find a list of the ‘things’ you want to start with. In our example this was a list of applications
Find as much documentation as you can about these things (functional descriptions, technical specifications, requirements documents)
Distribute to a group of stakeholders (process owners, application designers, business analysts)
Facilitate a workshop along the lines we just described
Either/or vs Both/and
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.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: