Week 10 - Gap Analysis, Migration Planning, and Creating the EA Roadmap

Gap Analysis

     Once you understand and document your current state and document what your future state will look like, you can perform a gap analysis.  A gap analysis is used to determine what will take to transition from current to future states. At my organization, once a gap analysis is performed, the application teams can provide a level of effort (LOE) on what it will take to fill the gap.

Migration Planning

     Migration planning is sometimes referred to as Implementation planning.  Migration plans describe in detail how you will transition from your current to future states.  Migration plans typically breakdown the work into sequential and incremental steps that need to be taken to reach your desired future state.

EA Roadmap

     An Enterprise Architecture Roadmap, is typically a graphical artifact that depicts at a high level, incremental capabilities that will be delivered over a period of time.  Below are two versions of EA roadmaps that I have used at my organization.

Figure 1 - Business Outcome Driven Roadmap

Figure 2 - Customer Solutions CRM Roadmap

Bagola, C. (2015). Business Driven Outcome Roadmap [Diagram]. Trappe, PA.
Bagola, C. (2013). Customer Solutions CRM Roadmap [Diagram]. Trappe, PA. 

Week 9 - Current State Documentation

Only If I Have To

     Rarely do I include Current State documentation as part of my Enterprise Architecture activities.  Time is limited and if I am able persuade the stakeholders why we should support an EA initiative without the this documentation, I forgo it and focus my time on other EA artifacts.   

     Gartner states that some understanding of the current state is needed for enterprise architecture planning, but many organizations get bogged down documenting too much.  They recommend that you document what you need in order to move your initiative forward, but not much more than that.

     I find the best way to win over your stakeholders is to explain - What is in it for me? (WIIFM)  Give them a reason to get in the boat and row!

     I will admit that there are times though when you've tried everything to convince your stakeholders why we need to do a particular EA initiative with no avail or you need this information to do a proper gap analysis and in these cases, you will have to resort to creating Current State documentation.

Bellah, B. (n.d.). What's in it For Me? Retrieved October 24, 2016, from http://butchbellah.com/whats-in-it-for-me/

James, G. A. (2006, November 29). Document Just Enough Current-State Architecture - Gartner. Retrieved October 23, 2016, from https://www.gartner.com/doc/498991/document-just-currentstate-architecture 

Week 8 - Future-State Architecture: Implementation Level (Part 2)

It's time to get your geek on!

(With your fellow IT peers)

     Detailed artifacts are necessary to convey your Future-State Architecture to your fellow Information Technology (IT) peers who are ultimately responsible to implement the solution.  All the countless hours architects spent discussing whether the Directory synchronization should be asynchronous or synchronous, pay off in the end, when you have a successful implementation.  If you don't take the time to "get into the weeds" with your IT heavyweights, you leave the implementation wide open for interpretation.

Figure 1 -  An example of a SharePoint one-way hybrid search architecture

     Share that same diagram with your business peers and you may end up with a endless amount of questions or worse, blank stares.  Once IT agrees to the overall implementation solution, I often create a high level implementation artifact so I can communicate our agreed approach to a broader audience.  The SharePoint Search diagram below is a perfect illustration on how you can simplify a similar message.

Figure 2 - SharePoint Search

     Be forewarned, outside of your IT bubble, this is what most people see when you get overly technical with your diagrams, spaghetti.

Figure 3 - Spaghetti Diagram

References:

Bray, S., P. C., & M. W. (2013, July 15). Microsoft SharePoint 2013 Designing and Architecting Solutions: Gathering Requirements. Retrieved October 16, 2016, from https://www.microsoftpressstore.com/articles/article.aspx?p=2224356

Ody, B. P. (2014, March 19). Untangle the system of system spaghetti. Retrieved October 16, 2016, from http://internetretailing.net/issue/beyond-channels-omnichannel-2014/untangle-the-system-spaghetti/

SharePoint Search. (2013). Retrieved October 16, 2016, from http://www.cairocodes.com/services/sharepoint/sharepoint-search 

Week 7 - Future-State Architecture: Implementation Level

Future-State Architecture
(Implementation Level)

     At my organization, Enterprise Architecture often creates implementation roadmaps that show how we are going to incrementally deliver business value.  And as we complete each deliverable it explains how we plan to move from our current enterprise state to our future enterprise state.

Figure 1 - Business Outcome Driven Roadmap

     Beyond this level of detail, Enterprise Architects will engage "the heavyweights" which include Solution Architecture, Application Architecture, Infrastructure UI/UX Designers, Networking and Security.  Collectively, we produce detailed implementation documents.  The Solution Architect is responsible for creating a solution sketch based on the information EA provides. The Enterprise Architect and Solution Architect will then meet with the other teams to ensure they have enough information to create detailed database models,network diagrams and as granular as documenting which blade server the application might be installed on.