ArchiMate Modeling in Practice – Fleshing out the MDM part


Subscribe
Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Sep 30, 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.

The team is excited about the news that they can go ahead with fleshing out the target architecture. They are particularly enthusiastic about going for a combination of best-of-breed systems mixed with an MDM solution. There is still some caution as Brenda has made it very clear that there was some ‘glazing over’ during the presentation. As before, the team decides to work in two sub teams: one team will do a “road show” to illustrate the concept of MDM to increase management buy-in, while the other team fleshes out the technical details.

Explaining MDM

Realizing that they target a mixed audience, the team creates a poster rather than a PowerPoint presentation, and makes sure that there is just enough there to warrant a good debate without adding too much technical details:

Poster explaining the concept of MDM - Archimate Modeling in Practice

They have set up meetings with all the executives and relevant staff for 45 minute lunch sessions. The results are somewhat surprising. The team started with an explanation of the challenges: what if you want a 360 view of your customer? What if you want to consolidate data and create a single view of your product and services across the entire enterprise? A siloed approach won’t work that well.  This meets with some skepticism (“Just dump the data in a single store!”) initially, but the example on the right makes it clear that this may not be as simple as it seems. Without going into the details, the team explains that there are various solution alternatives that all fall under the “MDM umbrella”. The target architecture will have to show which of the options is most relevant for the architecture of BriteLite, given its best-of-breed / data core approach.

The result of this exposé is that the skepticism slowly wanes. There may not be real buy-in yet, but at least there is no push-back either. The design team will have to do a good job of showing the solution alternative.

What are the options?

The “design team” meets on Monday morning and after coffee, cookies and discussing the latest sports results (“how about them Blue Jays, eh!?”) they gather in front of the whiteboard, and discuss the following assumptions:

  • We will select several systems that are best of breed, for CRM, ERP, MES etc.
  • A full list of functionalities will be decided on later. The details are not so important, but the integration mechanism is
  • We may select a single vendor with a suite but we could also go for separate systems from different vendors

Initially there is quite a bit of debate on the vendor issue, until one team member suggests that this is not a decision they can make on short notice as it all depends on a more thorough analysis of Brainstorming over options of systems to invest in - Archimate case studyrequirements and offerings. In other words, the team will have to work on two scenarios as illustrated by the whiteboard sketch. A more definite course of action will be decided upon based on the discussions. The team expects this to be a ‘tough sell’ as MDM solutions require a lot of up-front investment that must be made before the benefits can be reaped.

It is decided that Brenda will have to open up this discussion with management and the team that is working on the three strategies. In the meantime, the team will start working on the co-existence pattern with a focus on systems, integration / data, and relevant capabilities

MDM – the co-existence pattern

The team starts by exploring the co-existence pattern in more detail. In this pattern, all source systems keep their own data, based on the data model specific for the source system. All source systems are connected to the MDM hub which receives every update in the source system to any of the data entities that are managed by the MDM hub. The MDM hub make sure that these updates are also pushed to other systems in the landscape, including other source systems, downstream systems, as well as analytical systems. The MDM hub uses dedicated functions in order to define and maintain “golden records” for a range of data entities. The team created the following diagram describing the co-existence MDM strategy, which provides the team with excellent guidance for creating the target architecture specific for the BriteLite organization.

Archimate diagram modeling application components and flow relationsThe diagram uses the usual ArchiMate concepts to model things like application components and flow relations. By using specialization of ArchiMate concepts, the different MDM roles of the objects in the diagram can be visualized. In this case, specialized objects are identified with an icon: the application component with the crown icon is an MDM system. Application functions modeled as part of the MDM hub include data storing functions (the database icon), and processing functions (the double gear icon).

The team then starts building on this pattern, and creates a first draft of the target application landscape for the standard capabilities. The landscape is visualized below. The transaction systems CRM, ERP, and MES should provide functionalities according to the needs of BriteLite. However, as concluded before, a full requirements analysis of application functionality is yet to be made. At this point, only the data storing functions are identified as part of the transaction systems, other functionalities will be added to the model at a later point in time. For now, the diagram focuses on the integration aspect of the architecture based on the co-existence pattern.

First draft of target application landscape - Archimate modeling in Practice

While the view is very “high-level”, the team is happy to be able to visualize why the MDM-solution is important for BriteLite. This diagram is expected to help in discussions on data quality, being able to deliver operational / management reports quickly, and to make sure that the various systems have access to the same data.

The team also starts thinking about the deployment perspective of the target architecture. The diagram above identifies the applications and shows that data is exchanged between components. Using technology layer concepts from the ArchiMate language, the team models an initial overview of the target technology landscape. This identifies technologies such as ESB and ETL that provide functionality to support the exchange of information among objects in the IT landscape.

Diagram identifying applications and data exchange between components

The diagram serves as a starting point. In a later stage, more detail has to be added including the database platforms and application deployment technologies to support the application landscape. For now, placeholders already have been added.

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