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.
Early in the week, the baseline team announces that they are almost done with their work. There are a few more points to flesh out, but overall the structure is there. The team has brought along the following diagram to illustrate their way of working:
Brenda is quite proud that her team manages to convey their approach so well, especially when the baseline team explains that they have also used the modeling tool to generate several layered views to verify insights with stakeholders in the organization. They intend to publish a small set of these layered views as posters by the end of the week, together with all the cross tables. The HTML report on the intranet site is also to be updated with the latest insights.
At the end of the team meeting, Brenda asks the baseline team if they require further assistance to make sure the deadlines are met, and encourages the team to also write a newsletter that will be distributed to all stakeholders in the organization. The team is confident that they will make the deadline so everyone can go back to their task.
At the end of the week, both the baseline team and the target team are proud to announce that they have completed their task. The baseline team gets to present their findings first, and distributes big sheets of paper that show the cross tables they have made:
Application x Capability Matrix generated using the BiZZdesign Enterprise Studio
Node x Application Matrix generated using the BiZZdesign Enterprise Studio
They have also printed out several layered views, and explain that they want to do a demo for interested stakeholders to show how easy it is to do analyses on the baseline model. This idea is well received and the team will schedule this for next week.
The target team has worked on a presentation that illustrates the business-focused nature of the target architecture, and illustrates the main concepts of Pace Layering and BiModal IT, as this is the basis for the target architecture. It also shows the relation to the MDM components in the systems of record layer and explains the way this maps to the business strategies that are close to being signed off.
This (first) part of the presentation goes quite well. Especially the business focus, and the different development “paces” are well received. However, there is also some impatience and push-back: management seems to be in a “we-are-different” mood, and is not looking for “academic” discussions on development pace. With that in mind, Brenda decides to only briefly mention the need to think ahead, to consider “smart lighting” in the context of the Internet of Things, and moves on to the architecture framework to illustrate the line of thinking for the target architecture.
She pulls up a simplified PowerPoint version of the results from the brainstorm and sets out to explain how, in this setup, data will be the core of the architecture. The SOR layer will be built with standard, off the shelf tools, including a Master Data Management hub – and is careful not to go into detail as to what that entails: this is a discussion for next time. It will be supported with (data management) processes to make sure data will stay consistent and of high quality.
Continuing the discussion, she then explains how best-of-breed systems can be purchased to support the key capabilities of the organization. This requires strong data integration, a topic that will be discussed later. She also links back to the general notion of supporting manufacturing with a standard Manufacturing Execution System (MES), while keeping the new policies in mind. This will streamline planning and production processes while the separate “data core” (systems of record) entails control over the data.
While some people seem to “glaze over”, several of the key players seem to understand the benefits of such an approach, but sense a “catch”. After explaining that flexibility and control isn’t “free”, she argues the case for an integration layer and stresses the cost/ benefit aspects rather than the technology itself. In her presentation she tried as much as possible to make clear that the advantages of using an integration layer fit really well with the ideas of the target architecture that her team came up with so far. But at the same time, there are arguments against adding an integration layer into the enterprise architecture, as shown in the table below:
Supports loose coupling of applications (Systems of Differentiation)
Higher cost through additional technology
Central management of data (promotes reuse of data for reporting, easier auditing)
Higher complexity because of extending the application/technology landscape
Opportunity to leverage use and analysis of integrated data that otherwise remains separated
Increased vulnerability (single point of failure)
Scalability, easy to plug in additional source and/or target systems
Requires an Enterprise Data Model that all stakeholders should agree on
Supports “think big, start small”, easy to adopt and implement in an incremental and controlled way
Requires solid and coordinated organization in terms of (data management) processes
Advantages and disadvantages of using an integration layer in the Enterprise Architecture
While, again, there is some push-back, there is also support for her approach: management appreciates being involved so early, but doesn’t understand enough of the impact to decide either way. Understanding the need for approval / guidance, the agreement is that the team can continue for now, but will have to come back with a more formal analysis later.
Brenda shares the good news with her team and gives them the green light for scheduling some modeling sessions for the target architecture, starting with the IT landscape.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: