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.

Week 6 - Future-State Architecture: Conceptual Level

Future-State Diagrams
(Conceptual Level)

     Future-State Diagrams are in my opinion one of the most important and most frequently used Enterprise Architecture artifacts.  For that reason, I spend a great deal of time on these documents to make sure they 'tell the story'. Being able to reach a common understanding with regards to our end state with your stakeholders is critical.  Nothing does a better job at this than Future-State Diagrams and there is no single way to describe your Future-State.  Below are a few examples.

Future-State Diagrams can describe what a new process flow (swim lane diagram) will look like.  

Figure 1 - Future State - Car Sales Process Flow

They can be used to describe how systems will interact with one another.

Figure 2 - Integration of IBM storage systems with a VMware environment

They can also depict what your future architecture will look like.

Figure 3 - An Introduction to Enterprise Architecture

References:

Bernard, S. A. (2012). An introduction to enterprise architecture (Third ed.). AuthorHouse.

Concept Diagram. (n.d.). Retrieved October 03, 2016, from https://www.ibm.com/support/knowledgecenter/HSG_ISIS_110/UG/isis_ug_ch1_concept.html 

Enhance business process flows with branching. (2016). Retrieved October 03, 2016, from https://technet.microsoft.com/en-us/library/dn887193.aspx

Week 5 - Understanding Business Context (Part 2)

Your Hoshins (goals) are not the same as my Hoshins?

     At my organization, we use Hoshin Planning to define our Mission, Values, Vision and Annual Goals.

     Lean Productions provides the following description:  Hoshin Kanri (also called Policy Deployment) is a method for ensuring that the strategic goals of a company drive progress and action at every level within that company. This eliminates the waste that comes from inconsistent direction and poor communication.

     In general the Hoshin Planning technique is a sound process, although there is one disadvantage that I am particularly aware of.

     Each department has different goals, which in general is not a problem, but at our organization we often lack the Horizontal Alignment that is depicted on Figure 1 - Hoshin Planning Diagram provided by Zeeshan Syed.  What this means is that each department has no real incentive to assist any other department with their goals and without the Horizontal Alignment, it does not foster a supportive culture within the organization.

          Figure 1 - Hoshin Planning Diagram          

References:

Hoshin Kanri. (n.d.). Retrieved September 26, 2016, from http://www.leanproduction.com/hoshin-kanri.html 

Syed, Z. (2016, March 30). How to 'Think' like Toyota - Apply 'Hoshin Kanri' .. Retrieved September 25, 2016, from https://www.linkedin.com/pulse/how-think-like-toyota-hoshin-zeeshan-syed-ذیشان-سید-

Week 3 - Launching Enterprise Architecture Initiatives (Part 2)

Why are SMART goals, so HARD?

     We all know when launching an Enterprise Architecture initiative, you want to measure your success.   There are even guides to help us remember how to create goals that are Specific, Measurable, Attainable, Realistic and Timely (SMART).  There is no shortage of books, articles, templates and examples to show you exactly how to document and measure success.

     So why is it so hard?  Because all of this assumes that you have well documented baseline metrics, which in most cases, I do not. And in Corporate America where I work, it is nearly impossible to obtain the necessary baseline metrics either because they don't know or simply don't want to share this information with you.  

     I'm not alone.  The Office of Inspectors General in July of 2014 released an audit report stating that the FAA LACKS THE METRICS AND DATA NEEDED TO ACCURATELY MEASURE THE OUTCOMES OF ITS CONTROLLER PRODUCTIVITY INITIATIVES

"FAA has been unable to demonstrate the results of its controller productivity initiatives largely because it has missed opportunities to assess their effectiveness. For example, FAA did not establish detailed baseline metrics or quantifiable cost and productivity goals for 43 (84 percent) of its 51 initiatives. A lack of baseline goals creates substantial challenges for FAA to ensure these initiatives are effective. In addition, FAA is not maximizing operational and financial data regarding its controller workforce. The Agency does not systematically collect or analyze these data to reduce cost or improve productivity due to a number of barriers. These include a lack of requirements and guidance for facility managers on analyzing existing data, FAA’s inability to reach consensus on which metrics should be used to measure controller productivity, and data control and entry weaknesses with controllers’ time recording system. As a result, FAA cannot demonstrate whether many of its initiatives have had the desired efficiency gains. However, FAA has taken steps to improve data collection by issuing guidance to clarify procedures for recording employee time and plans to make further changes to improve how it tracks and allocates controller time in the system."

    My guess is that there aren't any dedicated resources / department responsible to collect and capture metrics.  Yet it amazes me that I'm always asked at my annual performance review - What business value did you bring to the company, when they know the challenges we face measuring success.