EA Roadmap – Gap Analysis and Migration Planning

Enterprise Architecture is a strategy domain, practitioners are focused on achieving business outcomes. The way to achieve Business outcomes is not always a Technology solutions, it can be People, Process or just information as well. (Some people believe Information is part of Technology, just think who owns the Information aka Data). Anytime I visit any organization or meet an Enterprise Architect, my first question is “Can I see your EA roadmap?” (depending on their answer it may be my last question); and the second question is “When was it last updated?”.

You would be surprised, how many times I hear, “we have a roadmap, but we are updating it” or “We have an executive roadmap for next X years ” (where x is never less than 5). The roadmaps are not based on any analysis, real data, strategy to execute or sometimes even desire to achieve it. I believe the main reason for that is there are not that many architects understand the need for one or know how to build it. In common sense, the roadmaps are developed because executives wanted a roadmap. There is no secret sauce for building a roadmap, it is simpler recipe than making a guacamole,

1. Gather business strategy →  Develop Target State Architecture
   It is very important to develop Target state first unless you have a vision. The most important quality for an Architect, and I don’t care if Gartner disagrees with me here, but Architect without Vision is just out of college developer. Develop future state as much as you know can envision based on business need. Stay away from over engineering. The amount of future state will decide how much and what needs to be captured for Baseline. Document the future state with a clear guideline because you need to use similar documentation strategy when it comes to Baseline as well.
2. Analyze current state → Develop Baseline Architecture
   Gather enough evidence to prove your case, demonstrate drawbacks of baseline. Beware not to get too much involved in Baseline, unnecessary current state documentation can be disastrous and time-consuming. Except for gap analysis, nobody care about it.
3. Find Delta between Target State & Baseline → Gap Analysis
   Now remember the fun does not start until you are at Step 3, Gap Analysis. Collecting similar details in Baseline and Target is very important, otherwise, the Gap Analysis won’t produce the results you need. Gap Analysis is nothing but

   [Gap] = [Target State] – [Baseline]

   You cannot subtract apples from oranges, can you? Also, it will be very difficult if the artifacts created are not assumed at the correct level of fidelity. Keep the abstraction i.e. Conceptual or Logical same when creating baseline and target state.
   I will be easier if you “divide (more like separate) and conquer it“. You can separate architecture components that will be compared by Architecture Domain (ex. Business, Information/Data, Application, Technology) or Architectural activity (ex. Process, Incentive, Technology, Organization or Functional)¹, or even metamodel entities (ex. Business Services, Application Components, etc). Whatever your strategy might be, keep it consistent when you are gathering Baseline and Target state.
   Gap Analysis can display additions, modification or deletions to Architecture Landscape.

4. Prioritize and Optimize → Roadmap
   This is the most important to capture, you need to develop a prioritized list of activities to achieve the Target state, it is very easy when you have your business partner close to you. The units of work that you documented with split categories that you decided earlier use them in your roadmap. Arrange them in prioritized sequence and attaching well-informed timelines gives you the roadmap. You also need help from your solution architect and/or SMEs to develop timeline or priority is very important. You may also need to think about dependencies between these small units of work. The dependency, timeline, and priority will complete your roadmap.
5. Date it
   This is the most important step of all, seems very small but provides the most value. Before publishing your roadmap, remember to put Updated Date and Next Update date on your roadmap. It keeps a reminder to update it often, the update frequency dependent on you organizational need.

Your roadmap does not need to be fancy, but it does not harm to make it fancy. Presentation + Content is very important for adoption.

Here are some fancy and interesting examples.

1. Parnitzke J, The Pragmatic Architect, How to build a Roadmap, https://pragmaticarchitect.wordpress.com/2011/03/05/how-to-build-a-roadmap/

Comments