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 

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.

Week 4 - Understanding Business Context

At my organization to better understand the business context, we begin by drafting a High Level Requirements (HLR) document.  Our HLR is not as detailed as the Common Requirements Vision (CRV).  At this point, we need only enough information to provide a level of effort (LOE).  The request is only an idea and does not have funding to move forward.  

After the LOE is complete, the business relationship manger working with the business requester and enterprise architect will take the HLR and LOE and present this information to the Information Technology Request Review board (ITRR) for approval and funding (CapEx).  Since not all ideas move beyond this stage, we don't invest a great deal of time creating a plethora of artifacts.

Only ideas that have been approved and secure funding move onto being a project.  At this time, the enterprise architect will use her discretion and create artifacts that she deems are necessary to help transition the approved idea to a project.  At some point the project team is armed with enough information to begin project planning and execution.  For most projects the enterprise architect may roll off the day to day activities and only stay involved for status meetings or be brought in if they project needs to consult with the architect if foundational or major changes are needed.

The business requester is always eager and anxious to move forward quickly with the project and for the enterprise architect, it is a balancing act as to how much information is required to move things forward.  Too many artifacts, the business requester grows impatient and sees IT as someone that is an obstacle and not an ally.  Not enough artifacts, the project team is uniformed and likely not to understand the business ask.

Week 2 - Launching Enterprise Architecture Initiatives

Launching Enterprise Architecture Initiatives is often challenging because in the early stages you typically start with an underdeveloped concept and a boat load of ideas that are overwhelming and unorganized. From any concept you start by beginning to understand which capabilities you are trying to build or mature.  Documentation allows you to present the ideas and supporting facts to a larger audience for stakeholder support and engagement. It is the stakeholder support that helps propel the initiative forward.

For years our Customer Service department had discussed, but never managed to implement a Customer Relationship Management (CRM) tool - Agent Desktop, that they sorely needed.  

After I joined the EA group, my first assignment was to find out why previous launch attempts failed and overcome those obstacles. As much as it irritated the business to start the discussions from the beginning again with another IT person, it was necessary, because although there were a number of business and IT folks who worked on this concept over the years, there was little to no documentation.  

One of the biggest reasons they failed to launch was that they were trying to 'boil the ocean' and didn't have a way to communicate to others their vision, goals, and strategy.

I'm happy to report that the first phase is currently in beta with several business units.  Initial feedback from management and CCR's is extremely positive.  And because they are well into execution, I am no longer actively involved on a daily basis.  It is always hard for me to transition off a project that you worked so hard to get off the ground.

Week 1: Review: Enterprise Architecture Foundations

If I had a dollar for every-time someone asked me... 

What is Enterprise Architecture?
And what does an Enterprise Architect do?

Scott A. Bernard offers the following simple equation:
Enterprise Architecture = Strategy + Business + Technology (EA=S+B+T)
This is always the easier of the two questions for me to answer and for others to understand.

The second question is much more difficult to explain because the answer often varies. Sometimes I'm creating artifacts to convey a concept, most of the time I'm heavily focused on people and change management.  In my own EA group, I'm often told I am too involved in the execution side of things.  I disagree, without applied EA, you just have bunch of ideas and fancy artifacts.

I think the important take away for Enterprise Architects is to understand what is needed to move your organization in the direction for the area you are focused on, which depends greatly on how mature the capability is.