Week 15 - Course Wrap Up

So many Enterprise Architecture artifacts 
and toolkits, so little time.

     There is no shortage of artifacts and toolkits to describe your Enterprise Architecture initiatives.  EA 872 exposed us to a plethora of Gartner Toolkits that allow for analyzation, justification and communication of solutions for enterprise architecture problems.  Artifacts in this course were presented in a order to reflect how a typical EA initiative may evolve.

• Launching Enterprise Architecture Initiatives
• Understanding the Business Context
• Future-State Architecture: Conceptual Level
• Future-State Architecture: Implementation Level
• Current State Documentation
• Gap Analysis, Migration Planning, and Creating the EA Roadmap
• EA Governance
• EA Measurement
• IT Strategy

     
     The challenge I often face with any EA initiative is that there is only so much time to spend on creating artifacts and leveraging toolkits.  Given real-life time constraints, I select a few artifacts (on average five) that are the most beneficial to EA initiative.  This course expanded my knowledge of available artifacts and toolkits.

Week 14 - IT Strategy

IT Strategy

     Is your IT and Business Strategy Aligned?

     Most people understand that Business drives IT and IT should enable the Business.  This alignment can only happen if IT understands the business strategy.

Figure 2: Aligning IT with Business

     One of the most difficult tasks I face at my organization is getting the business to give us a business strategy so IT can support them.  I've been with my company for eight years now and I have never received a written business plan.  The best materials I received was in the form of a PowerPoint presentation that listed each business initiative, which Hoshin goal it supports and some high level bullet points listing ways in which they plan to reach their goal.  The IT involvement 'section' is nothing more than a single bullet point, which amounts to a phrase or two sentences at the most.

     We'll extract the IT bullet points, create a spreadsheet for tracking purposes and scheduled meetings with the business to understand what their expectations are of IT.  One of the last items we receive is a prioritization of the requests.  All of this makes it nearly impossible for IT to support the business in a timely fashion, which in return, frustrates the business.  I've pressed the business and created a roadmap of capabilities, only to have them renege just a short time later.  Our business partners change their minds so often that it would be a full-time job keeping the roadmap artifact up-to-date.

     

Combrinck, J. (2010, August 30). Align IT with Business Strategy. Retrieved December 04, 2016, from https://www.spaceage.co.za/business/align-it-with-business-strategy/

Week 13 - EA Measurement

EA Measurement

There are so many different ways in which you can measure the success of Enterprise Architecture.  Below are 7 Key Metrics that Simplicable.com lists for Enterprise Architecture.  

1. IT Total Cost of Ownership (TCO) as a Percentage of Revenue
2. Total Cost Savings (TCS) 
3. Percentage Of Spend That's Strategic (PSTS)
4. Common Services Compliance Rate (CSCR)
5. Architectural Due Diligence Rate (ADDR) 
6. Sunset Technology (ST)
7. Business Specific

All the metrics listed above is good information, but I think there is only one metric that matters more than all the rest.  

Did EA help the Business reach it's business goals and metrics?  You can meet or exceed every independent EA metric available, but if you didn't help the business meet their goals, the value of EA will be perceived as low.  If you have to rely on all the other metrics available to prove the value of EA, you might be doing it wrong.

7 Key Enterprise Architecture Metrics. (n.d.). Retrieved November 20, 2016, from http://arch.simplicable.com/arch/new/7-key-enterprise-architecture-metrics 

Week 12 - EA Governance (Part 2)

EA Governance (Part 2)

     In 2014, my organization launched its Client Master Data Management project without an active governance effort. Client Data Governance is the decision rights or rule set for master client data in the Client domain. Client Data Stewardship is the operational or “day to day” work of Client Data Governance.  Figure 1 below outlines the Client Data Governance Framework.

Figure 1 – Client Data Governance Framework

     A Client Data Governance Committee was assembled and members include business and information technology subject matter experts from high impact systems and/or processes that create and enrich master client data.

Figure 2 – Data Governance & Stewardship Roles & Responsibilities

It is the job of committee members to:

• Attend twice per month committee meetings and participate in Committee meetings and sub-group meetings, as needed
• Represent their organization or function in approving artifacts and decisions, as well as establishing domain priorities
• Provide their subject matter expertise / process knowledge into issue resolution,  data discussions and any resulting decisions
• Be a source for reactive Client data issues 
• Proactively bring forward any Client data and/or process issue
• Alert this committee when there may be changes [i. e. process changes, system changes, etc. impacting Client data.
• Perform analysis and make recommendations regarding issues and process improvement
• Review and approve data definitions, business rules, measures, and metrics associated with the Client Master Data Management implementation and systems associated with CMDM
• Help drive cultural change [seeing our data as an asset]

Quest Diagnostics, & Schubert, C. (2015). Client Data Governance Framework [JPEG]. Collegeville.

Quest Diagnostics, & Schubert, C. (2015). Data Governance & Stewardship Roles & Responsibilities [JPEG]. Collegeville. 

Week 11 - EA Governance

Enterprise Architecture Governance

(We all know we need it, yet no one takes ownership.)

      Governance is a crucial component for any Enterprise Architecture program to be successful.  It is something we struggle the most with at my organization and I wonder if other companies face the same challenges.  EA does not have any authority, sufficient time, money or dedicated resources for governance.

     At my organization, we do our best to influence our business partners into to doing the right thing for our enterprise.  We however, do not have any authority to stop our business partners from deploying solutions that do not align with our strategic goals.  This has been very frustrating for me personally and at times I have requested that upper management intervene.  They decline, so I consider the matter closed.  You have to know when to stop "influencing" otherwise you are seen as a hindrance instead of helpful.

     Enterprise Architects are working on so many projects that often we don't have time to discuss what our governance program should even consist of.  And for the handful of times we conducted governance discussions, we rarely agree on anything and because of that, nothing actually gets implemented.  No one from EA is a dedicated resource to develop and enforce an EA governance program.

    Our Client Data Governance team has been trying to get our business team who creates client accounts to also become our operational data stewards (ODS) for two years now.   No budget ever includes money for ODS.  Yet countless conversations and time has been spent on this topic and it always ends with, we should schedule some more time to discuss.  It is nothing more that an elaborate game of hot potato.

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