- Adaptive Enterprise
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 work for gap analysis is in full swing. The team found the approach “a lot of work, but doable”. One of the team members justly remarked that “getting and modelling the information is one thing, but maintaining it will be another”. This is surely true, and Brenda is happy that the team is maturing rapidly, already thinking about the next cycle and keeping the architectural information up to date and valid. For the time being she decided that the focus should be on the current work. In the team’s working space she reserved an area on the whiteboard for “things to address in the near future” to make sure they are not lost.
The team has started with the information systems part of the landscape in their gap analysis. They keep it relatively high-level and the focus is on showing that the functionality of the system largely maps on existing functionality, yet the actual systems will change according to the new vision and target architecture. Part of the team also started working on a high-level gap analysis for the business layer, focusing on business processes and department structures.
During her weekly meeting with management, Brenda has indicated that the team is about ready for thinking about realization of the architecture. The idea is to setup a roadmap with plateaus and then worry about work packages and deliverables. In order to gain additional buy-in and speed up the work as much as possible, she requested help from one of the lead program managers of BriteLite. After all, program management is a skill and discipline in its own right and close co-operation will surely be beneficial. Management is quick to nominate Matt who is both very experienced and a big supporter of Brenda’s approach.
Together, Matt and Brenda work on a briefing for the team. Their first priority is to make sure the team understands that ‘all roads lead to Rome’… in other words, there is a choice to be made. Matt comes up with a simple diagram that – after some adjustment by Brenda – boils down to the following:
Both are well-aware that choosing an approach will require management support, yet they are confident that management will follow whatever advice that comes from the team. Each has its own advantages and disadvantages. After some debate, they decide to present this to the team before starting the actual planning.
Brenda knows her team well, and makes sure this is presented during a lunch meeting, agreeing that she will take the lead in this. Matt is a getting-results kind of guy and doesn’t mind at all. During the team meeting, the debate goes back and forth. Arguments are raised and discussed for all three approaches. For example, the fast approach is considered to be very risky, stressing the fact that big-bang migrations have a very poor reputation. The counter-argument is also made: a slow approach will reduce risk but doesn’t get us to where we want fast enough. No one seems to like the “cheap” approach, which is therefore quickly discarded.
Finally the team settles on a simple approach:
The direction is still fairly high-level but provides a good basis for furthering the road mapping and planning work.
With the approach agreed upon – at least for now – Brenda and Matt go back to the drawing board. They’re using the baseline / target modelling results to set up first draft of the high-level roadmap as follows:
The timeline shows not only the work packages (projects) to be executed, but also the plateaus: When CRM and MDM go live, we basically transfer from the baseline state, to the first intermediary state. That is when we start preparing and configuring the ERP system, which will bring us to the second intermediary state once we take it live, etcetera.
The team also starts detailing the roadmap, building on the models and gap analyses done in the previous phase. The complete roadmap, as described by the plateaus and the order in which they are organized (baseline plateau triggers 1st intermediate plateau, etcetera), is brought into the architecture model by the team, using their tooling BiZZdesign Enterprise Studio. On a detailed level, objects (applications, nodes, system software representing platforms running on nodes, etc.) are assigned to the roadmap. This allows the team to execute gap analyses on a more detailed level of the roadmap. The examples below shows (a part of) the effects of moving from the baseline state to the 1st intermediary state, from an application architecture perspective, and from a deployment perspective, respectively:
The results from the high-level roadmap are presented to the team by Matt, with support from Brenda: a good talk over dinner to line-up Matt’s ideas with the way of working that Brenda has in mind is all the prep they need. The idea is that Matt will help setting up the program so it seems to make sense to give him a platform to present his ideas and approach as well. While everyone agrees that the approach is solid and the analysis is valid at a high-level, the team suggests that (a) the analysis will have to be revisited as more detail becomes available, and (b) management should get on board as well. Chipping in, Brenda agrees and stresses that she wants to present approach + roadmap/ intermediates + high-level program plan as a whole to management a.s.a.p.
To kick off the discussion about planning, Matt presents the following diagram that he prepared with Brenda:
The assignment to the team is to come up with a rough break-down of the gap between baseline and the first intermediate in terms of deliverables. Matt would like these to be as concrete as possible, and include ‘hard’ things (i.e. systems installed, networks to be built) as well as ‘soft’ aspects such as training. The team gets a stack of sticky notes for their analysis with the warning by Matt that this is a preliminary analysis so it will be time-boxed to half a day.
After carefully studying the results and grouping deliverables into work packages in a modeling session with Brenda, the results that are ready for presentation are as follows:
In ArchiMate, as well as in the teams tooling BiZZdesign Enterprise Studio, the implementation and migration perspective is fully integrated. This means that the team can model, visualize, and analyze things like programs, projects, and work breakdown structures. The example above shows how the work for phase 1 is organized as a phased approach that consists of three steps executed in consecutive order. Each of the steps results in deliverables. Not only can these structures be visualized, but of course also connected to other parts of the enterprise architecture. Using this approach, the team can use the tooling functionality to perform analysis and present the results in e.g. a diagram like in the examples below. The diagrams show the result of an impact analysis of the individual steps of Phase 1 of BriteLite’s transformation initiative. The first example shows this from the perspective of the application landscape in scope for the first phase. The second example shows results of the same impact analysis, but from the perspective of the deliverables of the work packages, and how they impact the enterprise architecture:
This analysis performed by the team sets the stage for the next phase of planning transformation at BriteLite. In order to build consensus for the roadmap among BriteLite’s leadership team, Matt and Brenda need to focus on developing the business case: what are costs, business outcomes, risks, resource requirements associated with the roadmap. Not an easy task for Matt and Brenda to get the right numbers in place, but as we will see in the next episode, the BiZZdesign Enterprise Studio will be of great help for the team to add the relevant data to the repository and present convincing views and dashboards to get management on board!