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.