ArchiMate Modeling in Practice – Gap Analysis


Subscribe
Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Oct 28, 2013

Enterprise Portfolio Management, 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.

With the pressure on, the team has the feeling that they are “working around the clock”. Surely, the target model keeps growing fast, also because the reference models provide a good starting point. Still, the team has clearly stated that they had hoped to have more concrete results. This is probably due to the fact that a lot of people in the organization want to get started in realizing the architecture, rather than continually fleshing it out in more detail. Here, Brenda realizes she must strike a balance between getting a complete picture of the target architecture in ArchiMate® and giving her team what they want and need.

Where to start realization

Brenda decides to talk to her team first and bring them on board with her plans: get management involved in choosing where to start with the realization. She organizes a meeting in the ‘war room’ and shares her thoughts with the team. Usually her approach would be to stick to the plan and complete the gap analysis first, as she would hate to miss any important dependencies before choosing an approach to realization.

Based on what she’s seen from the models so far, it seems that either CRM or ERP are good places to start, and even the MES system might work – even though her gut feeling is to warn against it.

The team is only too happy to get closer to realization and after some back-and-forth about the claim that either system might be a good enough place to start a consensus is reached: let management decide. With a smile, Brenda suggests that the team keep working on the target architecture, cleaning up the ERP and CRM areas in particular, while she discusses the issue with management using the simple diagram that she has created using standard presentation software.

 

Management is starting to get used to Brenda’s visual style of presentation: she doesn’t send out huge memos, but brings a single diagram that keeps the discussion going generally. This time is no exception. Since she really does not have a preference as to where to start, it is relatively easy for Brenda to guide the discussion. Her main focus is to make sure that everyone understands that the first iteration will be hardest due to the fact that the complex integration layer will have to be set up. After promising that she will come back with a solid analysis, management gives her guidance to start with the CRM and come back with a plan a.s.a.p.!

 

Gap analysis

As usual, Brenda starts by preparing the team for the next step in the project. This time it will be about teaching how to perform gap analysis through ArchiMate’s implementation & migration extension, which will be new to most of the time. She prepares the following diagram:

Gathering the team, she starts with an explanation of the new concepts: plateau and gap (for details, see the spec). She illustrates these new concepts using three application functions: since A is in the baseline, but not in the target, it should be associated between baseline/target. For C the inverse is the case. Since B is part of both the baseline and target, it should not be associated with the gap, as simple as that. She also demonstrates that, with proper tooling, it should then be able to create color views that show the difference between plateaus.

 

Gap analysis for BriteLite

The approach is not difficult to understand intellectually yet the team suspects this is harder than it looks in practice, especially since some of the CRM system may seem the same between baseline / target, but are in fact different. Complex naming issues (homonyms, synonyms) will also be challenging. The only way to see how hard it is in practice is to actually get going!

The team decides on taking an approach where they start modeling at the highest-level, and then gradually drill down into more detail. In the diagram below, only the main components of (a part of) the new application landscape is visualized: the core transaction systems ERP, CRM, and MES, linked to one another by the envisioned MDM solution. Using the ArchiMate concept of the plateau, as explained so well by Brenda to the team, the “Target” plateau is introduced into BriteLite’s Enterprise Architecture model. The team uses standard functionality in their comprehensive tooling suite BiZZdesign Enterprise Studio. Although also in current day a CRM and ERP exist, all components in the diagram below are assigned to the Target plateau. In the target architecture, the functions of CRM and ERP will be chosen carefully, keeping a close eye on some of the important goals of this initiative: to not duplicate any functionality, as well as share common data across applications.

After the team decided on the approach, it took them only a few steps in the tool to get it documented and visualized as desired. Linking the objects in the architecture to the target state is enough to have the tool generate the picture below:

 

All objects, as well as relations, are colored in green, and the legend precisely explains what that means: the objects belong to the target state, or in other words: we are looking at a high-level overview of the target application landscape. Initially the team found it ‘funny’ that the whole diagram is green, very much in line with a ‘green field’ approach. The team realizes that a more detailed analysis is needed to get real insights that are needed for planning purposes.

As mentioned, the exact role of the transaction systems in the target application architecture is defined by the functions they provide, and the data they create, use, and/or manage. How this changes in the target state as compared against where we are today, the team needs to dive into the details. The team analyses at this level whether or not functions are carried over to the target state and by what system it will be provided. Also, new functionality will be available to support the necessary capabilities of BriteLite’s new operating model.

The team documents the results of their gap analysis carefully in their tooling environment. They do not have to start from scratch, but they are adding this notion of plateau and roadmap to their existing model repository. This means that they only need to make the link from their baseline model objects, and the target model objects to plateaus that carry similar names “Baseline” and “Target”. In their tool, they can link this using a table view, like in the example shown below:

 

After completing the exercise as described above, the repository contains enough information for the tool to do part of the hard work automatically: create an intuitive overview of the transformation of the application landscape going from the baseline to the target state. The resulting diagram is shown below. Again, an explanation of the colors is explained in an (also automatically generated) legend. In short: green is new, blue survives, though orange won’t. One of the things the diagram shows for the BriteLite case, is that functions/data around production management no longer will be provided by the ERP system, but rather will be transferred to the MES system.

This makes more sense: there are some elements that can be re-used, several can be ignored/ switched off, and a lot of it is new. It takes several iterations of validation to complete the picture, but soon the team feels confident that this captures the essence well enough: having a solid picture of the baseline, target state and their differences (gaps) in place, is indispensable insight for the next phase: planning the actual work!

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