EA 872 Week 10 How to measure the gap

Hello! Thanks for reading! If you have been here, before welcome back!
This week we had readings dealing with Gap Analysis and Road Maps among other items.  I started discussing some aspects of Road Maps in my week 8 posting here

http://joec3s.blogspot.com/2016/03/ea-872-week-8-route-planning.html

I also wrote some details about the project complexity assessment technique here in week 6

http://joec3s.blogspot.com/2016/02/ea-872-week-6-low-hanging-fruit.html

For this week, I am going to continue along with on an item I touched on at the end of the post, project complexity and gap analysis. Project complexity analysis is an assessment technique that can be used during a gap analysis effort. When moving towards a future state architecture, it is important to understand the impact of any given project or process. Complexity Assessment is the process of determining the scope and initial timeline of any project or sub-project associated with future state effort. Each effort is assessed based on its Requirements Complexity and Environment Complexity.  Each complexity dimension uses multiple evaluation criteria to accomplish a sensitivity-based assessment.

Requirements Complexity is a measure of how complicated it is for a  delivery team to provide the solution to the business users.

Environment Complexity is the measure of how well the current state environment supports the expected needs of the solution.

The goal is to map an effort, based on complexity,  into a project type (1,2 or3). You can get more detail on the "Types" in the week six link noted above. To pull this all together and better understand this process I have attempted to break out the complexity elements as I might approach them during an assessment effort. Assume that this is a Business Intelligence reporting or data analytics effort.


Requirements Complexity
Requirements complexity as stated  is a measure of how complicated it is for a solution delivery team to provide the reporting solution to the business users.  The requirements complexity criteria are listed below.

Graphical User Interface
Customization of ‘out of the box’ functionality:

• High – more than 20%
• Medium – under 20%, but greater than 10%
• Low – 10% or less

Analytics
How much analytic functionality is required in this solution?

• High – requires advanced analytics, newly defined business process.
• Medium – calls for advanced analytics, existing business process.
• Low – a take it or leave it.

Security 
What is the expected security level required for this solution?

• High – new security model required. 
• Medium – role and data level security; could have regulatory issues.
• Low – role-based, no expected issues.

Reuse Effort 
What is the expected reduction in effort due to the use of a reusable assets?

• High – less than 50%
• Medium – over 50%, but less than 80%
• Low – 80% or more

Expected Deployment 
How many users are expected to be using the deployed solution?

• High – over 500 
• Medium – less than 500, but more than 50
• Low – 50 or less

Environment Complexity
Environment Complexity as stated is the measure of how well the current deployment environment supports the expected needs of the solution. The environment complexity criteria are listed below.

Architecture Development
What is the expected need for new architecture components for deploying this solution?

• High – new architecture required (source data – staging – repository – reporting) 
• Medium – new repositories and/or data mart required
• Low – existing deployment environment sufficient

Software & Hardware
What is the match with the currently deployed software and hardware within the development and deployment environments?

• High – None, new software and/or hardware platforms required
• Medium – some new hardware or software required, but not currently used in other deployed solutions
• Low – current environment meets needs

Data Sources
How many new data sources are needed?

• High – more than three new data sources required
• Medium – 1 to 2 new data sources required, but sources not qualified and/or new transformations required against current data sources
• Low – no more than two new data sources, but from qualified sources

Reports 
What is the adequacy of the current reporting capabilities?

• High – new business reporting required
• Medium – expanded reporting required, needs business validation
• Low – current reports, interactive features only

Business Rules Development 
Are there existing business rules that support the reporting requirements of this solution?

• High – new processes being developed, business rules dependent on completion
• Medium – new business rules required for current or new reporting
• Low – existing business rules used in current reporting

As I noted above getting to that project type is the ultimate goal of this effort. This classification can then be associated with timelines and cost thus adding tremendous value to the gap analysis efforts.
This information, in turn, helps ensure effective expectation management from the very early stages of project inception.

If you want to see something similar in action look at this link for the Canadian government. 

http://www.tbs-sct.gc.ca/hgw-cgf/oversight-surveillance/itpm-itgp/pm-gp/doc/pcra-ecrp-eng.asp

This approach is quantitative with the way it scores out and the added depth it takes. 

Thanks again for reading and as I stated last week I hope this starts to tie together these past posts into a more useful framework.

EA 872 Week 9 Starting to pull it all together

Hello again! Welcome back from our short break and thanks for reading.
This week we have been discussing "Current State" documentation.  That's a fine segway from all the future vision discussions that we have been having these past couple of weeks.

There is no simple or direct method of establishing the current vision. In my opinion, this is where most of the trip ups occur. My reason for saying this is that it is not a strictly technical exercise. One can not just fire up a modeling tool of choice and run out to document the organization.  We can have great modelers and an understanding of architecture standards and supporting technology. But that only gets us so far. An EA practitioner must also understand the dynamics of the business and culture, so that outside influences can be determined and accounted for during this documentation effort.  If you are wondering why should you care as an architect...how else can you understand where to start? Should you begin with that one off database maintained by some LOB? What about the CRM system or the online ordering system? How do you get focused and know where to start?

Understanding the business is the first step. Do you understand the enterprise's missions and objectives? Does this match the CEO and other C-level executives goals? From there, that can lead to those critical solutions or areas of the business that you should direct your focus at to start. On your team do you have a resource with a thorough understanding of the company? If not, no amount of technology will help you from getting bogged down and lost with little value delivery.  Thus, to be effective at working through the current state and getting to some of the documentation we have discussed, one needs a supporting and repeatable framework to assist in this process.  The first part is to establish a set of questions that can pull relevant information from key stakeholders but can also be quantified.

One industry model is the Mike2.0 framework which can be found here

http://mike2.openmethodology.org/wiki/Information_Maturity_QuickScan


This provides a nice format to collect data and produce results that are quantifiable. with some nice Gartner type four quadrant graphs. My concern is that this might produce to much data and come across as overly complex in the final analysis, depending on the the audience.

If you look back on my blogs, you will see some references to defining key metrics and using responses to drive information acquisition.

One example can be found in Week 7 - Delivery Approaches

http://joec3s.blogspot.com/2016/02/ea-872-week-7-delivery-approaches.html

Another example is found in Week 5 - Getting on the Same Page

http://joec3s.blogspot.com/2016/02/ea-872-week-5-getting-on-same-page.html

I discuss two techniques that I believe are excellent at getting this relevant information in a quantitative way.  They are the SWOT with a storyboard and then GQM (Goal, Question, Metric).  This type of visual has proven to be effective with C-Level executives and yet provides information and details that can be quantifiable.  I will not repost those details again in this week's blog, but take a look back if you have a chance, and let me know what you think.

Hopefully, this post starts to tie together these items that I have been writing about these past weeks into a more useful framework.

It would be great to hear about what has helped you with useful current state analysis techniques.

Thanks for stopping by and as always I appreciate your thoughts and comments!

EA 872 Week 8 Route planning

Over the last couple of weeks, I have been writing about different aspects of past work I've done and how that relates, in my opinion, to the academic and formal definition of EA and its principles. Based on some of the comments I have received, it seems that I have pointed to some items that others have found interesting. I know I have found the comments and discussion to be informative as well. At this stage, it would seem like it makes sense to keep on that path. Hey, if something is working for you , why change? Isn't that how the saying goes? How many folks have heard that during a project!? None the less, I'm going to keep on the same path this week and discuss roadmaps.

Roadmaps are an essential part of the Future Stage Architecture. A Roadmap is a visual representation of the future vision and an important artifact for executives and decision makers. For the team, it is a major component of the planning process.  How do we get to this map...the artifact that is intended to help us plan the route from current to the future state?  CIO magazine reports that the EA roadmap is the linchpin for transformation.

"Achieving a transformed ‘future state' requires a tool to guide and govern day-to-day resource investment decisions - the Enterprise Roadmap."

http://www.cio.com/article/2372268/enterprise-architecture/the-essential-ea-toolkit-part-4---an-enterprise-roadmap.html

So, how do we build this and what does it look like when completed?  In the past, as part of larger strategy and planning efforts, I have attempted to develop an approach that assists in this roadmap planning process.

This process starts with identifying potentially harvestable assets and using those to create a "candidate asset list." Then we would go through the following planning process:

• List upcoming and existing projects.
• Eliminate projects that do not have high affinity.
• Identify key services required by these projects.
• Analyze the candidate asset list.
• Perform market analysis and technical/cost benefits analysis on the candidate asset list.
• Identify potential assets to be provisioned in the next quarter.

The context of the  planning effort can be visualized as depicted below.

The hardest part of this process was getting a group to perform an appropriate asset analysis and determine how it ties back to the business and its place in any given market. The flow of this analysis was to determine the appeal to the company, determine the competitive position, establish the market opportunity and then decide if a cost benefits analysis was required.

This resulted in an easy way to visually measure and demonstrate the value of any given asset in the planning process. By creating a graph of attractiveness to the market by competitive position, one can show what assets should be pursued now, in the future, or not considered.

Now the team can quickly review the asset analysis against projects and provide an easy visualization. This can then drive discussions around ROI, necessity, reusability and strategic alinement.  These are all items necessary for planning and gap analysis, an important aspect of the road mapping effort.


Thanks again for stopping by and reading! I welcome and look forward to thoughts and comments.