The Practice of Architecture Assessments

One of the most common tasks that an IT Architect will be asked to do across the course of their career is the Architecture Assessment. It is more common to conduct these if one is working as a consultant rather than an architect on an internal team, but even in those instances it is likely that an IT Architect will have to perform at least a few of these.

In the context of a larger solution lifecycle, the Architecture Assessment tends to occur most often in the initial phases (Discover, Analyse etc.), however assessments can occur at any point within the lifecycle as part of a problem-solving exercise or can occur entirely outside of the scope of any given solutions lifecycle. Assessments are disproportionately (in relation to time / dollars invested) important activities for a number of reasons:

1. It represents a dedicated effort to validate or discount core assumptions
2. It provides a mechanism for honest feedback (w/o fear of retribution)
3. It allows for rapid problem-solving and design exercises in environments where that might not otherwise occur.

Assessments are not a clear part of any particular EA Framework methodology (they may be implied in some sense), however that doesn't mean that they should be conducted in a haphazard manner. Assessments should be planned, estimated and designed in order to provide clear outcomes (be they recommendations, design deliverables or both).

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
• What if Analysis
• Feasibility Analysis
• Trade off Analysis
• Problem Space Definition & 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 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc