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

Read More

The Top Questions in a Build vs. Buy Analysis

Software is the lifeblood of most IT departments. So it’s logical that determining when to buy a packaged solution versus building a custom one for a given business requirement is one of the most common types of decisions they have to make. A "Build vs. Buy analysis" often represents a key component in a typical Architecture Assessment.

Usually, making the “Buy versus Build” decision involves both technical and business resources. How it’s done varies greatly from one enterprise to the next. Some organizations spend a significant amount of time deciding, while others focus more on analyzing the “buy” choices once it’s been determined that custom development isn’t going to happen. Still others bypass most of the process altogether and dive head first into a “buy” commitment.

For the folks who know for sure that they’ll be buying, the big question is often, “When?” This post will focus on situations where the buy decision hasn’t yet been made.

The Architect’s Role

IT architects are often asked to help facilitate the process. While they’re usually not the ones charged with making the decision, they’re often the people who provide the recommendation. If there is to be any formal analysis process, then the architect tends to conduct it.

Making the build-versus-buy decision necessarily precedes any product selection process. It should – but doesn’t always — come after some sort of preliminary needs assessment or strategy activity. If a strategy was developed, the capability might be defined at a functional level and even sequenced on a roadmap, though not defined in very much detail. The more information, the better of course, but even if there’s relatively little data to start with, some of the key questions you’ll need to ask will remain the same.

So, what are the most important questions to ask when approaching a Build vs. Buy analysis?

1. Is it really just build versus buy, or is it more complex? In other words, is there a third or even fourth option to include in your analysis? The most common of these include do nothing (or don’t do it yet) and build some, buy some (then you have to determine what proportion for each). It’s understood that many types of Commercial Off the Shelf Software, or COTS, are meant to be customized somewhat – like when you build reports in Cognos or Oracle BI tools. Other COTS require or allow very little customization. Understanding how customization ought to occur and how it’s handled in a particular package is vital to making an accurate assessment.
2. Is the solution redundant with an existing capability (either custom or COTS) and if so, is there a logical migration path to the new capability? And how will that transition be impacted by the buy versus build decision? This question generally implies that a transformation is in progress, and that usually involves added dependencies and constraints.
3. Do you already have a support model in operation or one in the works? For example, if you are thinking about expanding existing Oracle e-business applications, then having an Oracle standard LDAP tool might make more sense than a homegrown one. Also, support includes having people on-site or off who can troubleshoot issues for you in near-real time.
4. Does the business case (or basic proposition) align better with one option versus another? If the value proposition is that some type of ERP-like capability is needed near-term, then building something homegrown might be faster than deploying a major ERP COTS package.
5. Is your organization capable of delivering a custom solution based on the stated requirements? Not every IT shop can do everything – understanding your internal limitations will make a big difference in the overall solution. By the same token, some internal groups will place limits on what COTS (or even hardware needed by COTS) they will support.
6. What is the overall cost of doing one option versus another? Some folks refer to this as “Total Cost of Ownership.” It usually reflects the full lifetime expense related to the solution. It’s obviously more difficult to estimate this up front for a custom solution than it is for COTS, but that doesn’t mean that the COTS approach is always cheaper. Very often, answering this correctly requires some advance work in understanding support costs for existing systems in your own environment.
7. If someone expressed an initial expectation or preference up front, validate why. This is fairly important as it may indicate that the buy or build decision has been more or less made before the analysis even began. In this type of situation, the stakeholders may want the analysis mainly to provide support for and a risk assessment of their initial decision. So, you might ask yourself, what if the stakeholders’ initial decision is wrong? That’s a tricky situation since you generally don’t want to be in the habit of trying to deny the wishes of your employers. However, if you feel that there is a serious issue surrounding their direction, document it in the risks and note the possible mitigation that choosing alternatives might provide.

The format you use to highlight the results of the analysis can vary. More often than not, PowerPoint is used to convey the key results of the activity back to the stakeholders. In that presentation, capture the following elements:

1. Description of the Requirement.
2. Goals for the Analysis (and Process).
3. Description of the Technical “Problem Space” / Context.
4. Identification of Options (Build versus Buy, or More).
5. Ratings Matrix (with Explanation of Weights / Priority Applied).
6. Solution Recommendation.
7. Risk Assessment and Issues.

When conducting an analysis like this, the most important thing to remember is that there often aren’t slam dunk answers. In other words, the advantages between one versus another option may not be overwhelming. There may also be trade-offs to consider that help refine the recommendation. Ultimately, the answer that comes closest to being accurate is the one that assimilates client needs and constraints the best.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More