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.
Fleshing out the co-existence pattern was hard work for the team: Brenda had to coach them through the project, staying away from the technical details such as deployment until the concept is clearly understood and the actual go-ahead from management is obtained.
Even during the modeling exercise, the team agrees that the only way to show management the power of MDM is to work through an entire use case. In order to do so, they want to add at least a few details of the CRM system, the ERP system, and the MES system and use story boarding techniques to show how the integration will work. The team presents the idea to Brenda who is pleasantly surprised by the initiative. The only guidance she gives them is to use reference models whenever possible to figure out the main functions of each of the systems.
Selecting reference models
The team has a good meeting to divide the work. They quickly find out that reference models can be found at two levels:
Reference models pertaining to the manufacturing industry
Reference models from vendors
After a quick debate and some web searches, they find that a side-by-side comparison of several vendor models will result in a “good enough” reference model that can be used as the basis for the architecture. Even more, they decide to only capture the main functions as well as the main data objects, not worrying about infrastructure / deployment and other details too much.
After documenting this design decision and obtaining Brenda’s approval, the team gets to work. In the meantime, Brenda goes back to management and – surprisingly – has to take some heat!
During her weekly update session, Brenda is told that ‘management is happy with the general approach but results are ‘too slow’. Changes are being made, the baseline models help, but the “big picture view” is lagging behind and urgently needed’. This comes as a bit of a surprise, given the conversations and regular updates over the last few months.
There seems little room to find out what caused this – even though Brenda suspects it has a lot to do with an upcoming shareholder meeting, so all she can do is promise more speed. Happy that her team presented their thoughts earlier that day, she suggests that the IT part (but without the infrastructure – this will depend on the vendor) is to be presented next week. An illustration of how business capabilities are supported with the IT landscape will be illustrated the week after. And then the team will work on a rough roadmap for implementation.
The management team grudgingly agrees. When Brenda shares the news with her team, she makes sure everyone understands that the game is on!
Developing the reference model
The team has selected the following components to develop a reference model for:
The CRM system, which will hold all the data around relations, including customers, vendors, partners etc.
The ERP system will do anything related to planning, inventory management etc.
The MES will support the actual manufacturing
As a word of warning, Brenda indicates that they shouldn’t worry too much about synching up between countries … yet.
As a first step, team members try to find as much guidance on the use of reference models as they can find. After some searches on the internet, they find an article on the BiZZdesign blog website here: http://blog.bizzdesign.com/reference-architecture-models-with-archimate. Then they decide to document reference models in their EA tool BiZZdesign Enterprise Studio, by consolidating information found in industry and vendor reference material. In this way they build up a model for each of the core applications to be adopted by BriteLite: CRM, ERP, and MES.
This is far from easy, as the team quickly finds out. It appears that each vendor has its own unique ‘reference model’ and integrating them is a complex task. This is unfortunate since a vendor-neutral reference model can be valuable in this phase of the project. For now, the team decides to attempt to integrate models from various sources. Each of the applications is broken down into the key application functions that will support BriteLite’s business capabilities. The other part that is added to the models by the team is visualizing the key data entities that are part of the data model linked to the reference application architectures. The example below shows an early result where the applications are modeled using Application Components, with the assigned Application Functions nested in them, as well as the data entities modeled as Data Objects:
While the three core applications in the reference application landscape will have to provide distinct support for BriteLite’s capabilities, the reference architectures show that there are functions that are available in multiple systems. An important aspect of deciding on the actual target architecture for BriteLite includes making decisions on what functions will be required for each of the core applications, while making sure that in the overall architecture all functions required to support BriteLite’s business capabilities are available and aligned. The other aspect is to identify what information is managed in what application, and how it should be exchanged with the other application. For the actual exchange, the team will be building on the MDM patterns as explored previously.
The team analyzes the reference models of the core applications, and uses coloring to identify and visualize unique and overlapping functions, as well as unique and overlapping data entities. The example below shows one of the results of this analysis:
The diagram shows that some of the functionality and data typically available in the core systems overlaps with functionality and data in the other systems. The colors show these duplications, as explained in the legend. This diagram gives the team the insight that it is critical to define a key focus for each of the systems in the target landscape. The diagram helps the team to define the requirements for systems in support of the process of software selection. The overlapping data objects in the systems underline the added value of the MDM solution. The team is confident that working on the reference models has brought a solid foundation that will help detailing the target architecture. Next step: the target application landscape!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: