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.
Brenda’s “target team” feels like they’re in a tight spot. It’s great that management has given some direction for the IT/ sourcing / product strategies, but it doesn’t seem to fit with what they had in mind for the target architecture. In the meantime, the pressure is on as Brenda has been asked to present her thoughts on the strategies in the light of the target architecture.
For the time being, Brenda has put a ban on modeling things for the target architecture until a common approach has been agreed upon.
The baseline team therefore has full access to the repository and is working on links between the layers that they hope to present next week. Their approach is to work with cross tables and then generate some views to show how everything fits together. The cross tables they have come up with are:
Products & services x capabilities
Capabilities x systems
This should also validate the application services that have been defined
Systems x infrastructure
Which should validate the infrastructure services that have been defined
Also, the baseline team finished the application landscape. Using the BiZZdesign Enterprise Studio, they generated and published an HTML report for stakeholders to browse and analyze the content. The report allows readers to navigate the model and dynamically show / hide attribute information to get to the required level of detail. The example below visualizes BriteLite’s application landscape, showing application type as a color, and the operational-since date as a label.
The team working on the target architecture has spent most of the day on a brainstorm in front of the whiteboard. Several approaches have been tried and the team slowly gets around to the idea that strategy and the architecture framework can be reconciled.
After yet another coffee break, one of the team members hooks up his iPad to the projector and explains what he came up with during the break.
The key to solving the puzzle, in his view, is to consider a system as a collection of data and functionality. In that case, part of the system would be in the systems of innovation layer, another part of the systems of record layer. Moreover, the layer can be complemented with separate (master) data management stores for key entities such as customer and product. The reporting systems (a data warehouse) can also be in this layer.
The team wants to know why an MDM solution is required if we go for best-of-breed solutions. It is Brenda who can answer that: because several of these best-of-breed systems will require access to the same data! Using an MDM hub will also be a good step in getting a data management capability off the ground. She quickly pulls up a slide to show the key functionality of MDM systems to explain the line of reasoning:
The team agrees that this approach would solve many issues, but recognizes that it would also be expensive. Still working at the whiteboard, they figure out a story line to present to management that shows:
How the target architecture works
With a brief overview of BiModal IT and Pace layering
How the new strategies and target architecture fit together
What the consequences will be
Illustrating the cost (ball-parking, it is too early for a detailed financial analysis)
Illustrating benefits and risks of following this approach
Brenda will maintain the ban on modeling until management has approved this direction. While “waiting”, the team sets out to come up with a list of key applications + main functions + data objects that will most likely be used.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: