Monday, November 4, 2013

The Value of Architecture Assessments

While many people are becoming somewhat familiar with IT or Enterprise Architecture, relatively few know much about Architecture Assessments. This is unfortunate given the significant value proposition such exercises provide. For example, had one or more Architecture Assessments been provided for Healthcare.gov during the course of the project; it is unlikely that the Obama administration would have been surprised by the current mess it's now facing.

Problem Space analysis is one of the techniques used with assessments - it can apply
both to the business and technical aspects of a project

An Architecture Assessment is also different than other traditional Architecture activities in that the expectation is generally that third-party personnel are more likely to perform them. The reasons for this include the following:

  1. Assessments are one of the key tools involved in IT oversight activities (sometimes referred to as Independent Validation and Verification or IV&V).
  2. It is more likely that an accurate assessment can be obtained by architects / investigators without a vested interest in the project. 
  3. The skillset of the person doing the assessment is critical - it needs to be an architect and not merely a technical or product expert. This is the only way to ensure that all options / alternatives are properly considered / assessed. 

So what exactly is an Architecture Assessment? A typical assessment tends to include the following categories of activity:

  • Information Gathering  
  • Design & Project Review
  • Design & Project Recommendations
An assessment also typically includes one or more types of specific analysis as well:
  • Analysis of Alternatives
  • Root Cause Analysis
  • Problem Space Mapping & Resolution 
One way to capture alternatives is through Decision Trees.

Perhaps the most important function that an Architecture Assessment can provide is a mechanism to challenge assumptions and combat complacency. One of the main reasons that IT projects fail today is because there is generally no incentive or expectation to raise issues or problems. Rather than being viewed as a healthy activity - identification of the problems is feared in itself and thus ensures even more pain later on when the issue finally surfaces (which they always do).


When compared to the cost of the rest of a typical IT project (and any potential loss or cost overruns associated with problems that aren't identified or managed in a timely fashion), a relatively brief assessment exercise is generally less than 1% of total cost yet could make the difference between success or failure...



Copyright 2013, Stephen Lahanas


#Semantech
#ITarchitecture

0 comments:

Post a Comment