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