How Enterprise Architects Can Be a Business Person First

If they do it right, enterprise architects can add tremendous value to their organization’s selection of a packaged application solution. The architecture inherent in any new technology acquisition can have unintended consequences, and this is especially true with a major apps solution — whether it’s deployed on-premise or via software-as-a-service (SaaS).

Historically, in a packaged apps selection process, architects have often acted primarily in their role as the stewards of the organization’s technology standards. Their default assumption may be that they participate in the selection process to ensure that the final selection adheres to enterprise IT standards.

Why do architects tend to focus so heavily on standards? Because it just so happens that, all other things being equal, adherence to IT standards helps to achieve long-term value. And there’s the rub: Seldom are all other things equal, which means you can’t rely on the shortcut of mere standards compliance. Your proper contribution to a packaged apps decision is to analyze and estimate each candidate’s Architectural Business Value (ABV), which Forrester defines as:

The estimated Total Economic Impact (TEI), for a candidate solution, of: 1) ongoing costs incurred for process, organizational, and technical adaptations required because of a solution’s divergence from IT standards; and 2) ongoing benefits created by the solution’s comparative architectural strengths vis-à-vis other candidates.

Educating the selection team on the concept of ABV is your first challenge. From there, across the four phases — organize, narrow, evaluate, and decide — of the selection process, you will build initial ABV models, identify key factors that will affect ABV, test key factors and document their impact, and integrate ABV into the comprehensive economic analysis prepared by the team.

During The Organize Phase, Establish ABV as a Part of The Selection Process

As the team gets organized, your primary aim is for the team to incorporate ABV as a recognized part of the selection process. To accomplish this:

Establish your business credibility. Make it clear that your goal is business analysis, and that your technology analysis is only for the purpose of identifying business costs, benefits, risks, and future options.

Build support for ABV. Introduce ABV as the framework for your analysis. Describe it as a way of quantifying downstream impacts, hidden costs, and future opportunities inherent in today’s technology decisions.

Build ABV into the project charter. Among other things, the charter defines how the selection decision will be made. Your goals are for ABV to be a recognized, agreed part of the decision model and for the selection project to build in tasks and budget for assessment of ABV.

During The Narrow Phase, Build Your ABV Model

During the Narrow Phase, your goal is to identify, in priority order, the most significant factors that will contribute to the ABV of each shortlist candidate. Your assessment of the value of architectural strengths should be driven primarily by connecting these strengths to business strategies and objectives, not by mere assumption that modern architectures are good. To build your ABV model:

Make a quick first pass for each longlist candidate product. As the team identifies viable candidate products, quickly identify and itemize the most impactful ABV items for each, such as the package’s application platform and its support for modern architectures like SOA.

Provide the team with rough comparisons of ABV. As the team debates pros and cons of the various options and considers narrowing the field, provide rough, order-of-magnitude comparisons of the candidates’ relative ABVs.

As the team narrows in, deepen your analysis. As you have time, and as needed to make shortlist decisions, extend your analysis and develop initial order-of-magnitude monetary estimates first for the candidates that are gaining the most favor with the rest of the team.

Finalize your ABV model with the shortlist. As the team narrows in on two to five shortlist candidates and begins to develop its selection criteria, catalog the ABV factor differences among the shortlist, ignoring factors that are equivalent. Then, starting with those likely to have the biggest impact, build a model for the detailed ABV analysis to be done in the Evaluate Phase.

During The Evaluate Phase, Complete Your ABV Analysis

To complete your ABV analysis, you will do both paper-based and lab-based work. Among the items to test, consider validating whether a vendor is fairly claiming support for your standards. Assume that you won’t have sufficient time to analyze every major ABV factor, so proceed in priority order, starting with the factors likely to have the highest impact. To complete your ABV analysis:

Construct and conduct lab tests with each candidate. Whether in your lab, in the vendor’s lab, or over the Internet (for a SaaS product), conduct specific tests to validate and assign values to the factors in your ABV model. It’s not necessarily required that you conduct the same tests with each candidate, since each candidate’s ABV factors will be different, but you should be able to defend your reasons for any differences in testing.

Conduct paper-based analysis for remaining ABV factors. For ABV factors that can’t be tested in the lab or for which you won’t have time to test, do paper-based analysis. What new IT operations procedures will be required? Will non-standard technologies require the organization to hire new staff (or to cut back on levels of support for other apps)? How much will it cost to keep your developers up-to-speed on technologies that fall outside your IT standards?

Incorporate your ABV analysis into the team’s TEI analysis. With your lab results and paper-based analysis in hand, finalize the risk and flexibility aspects of your ABV analysis.

During The Decide Phase, Support The Overall Business Value Winner

Once you have incorporated your ABV analysis into the rest of the team’s analysis, it’s time to close the loop on your credibility as a businessperson: Put on a purely business hat and support the product that delivers overall the most business value to the organization.

Besides packaged apps selection, architects may be involved in many other organizational and architectural decisions that are fraught with politics. Business executives distrustful of IT often want the fastest path to any solution. Application delivery teams with project deadlines to meet are often impatient with architectural restrictions.

As enforcers of IT standards, architects often prioritize consistency above business value. For many types of decisions involving business technology architecture, Architectural Business Value allows architects to reframe discussions away from architectural standards toward the bottom line of the business. It won’t eliminate politics, but it can reduce them while building credibility for architects as businesspeople, which they should be, anyway.

Randy is Vice President, Principal Analyst at Forrester Research. He is a leading expert on architectures and design approaches for building enterprise applications that are secure and resilient in the face of continuous business and technology change. This makes service-oriented architecture (SOA) one of Randy’s primary focus areas. Since enterprise applications need much more than SOA, Randy led the development of Forrester’s Digital Business Architecture, which provides a broad architectural context around SOA. For seven years, Randy has been a driving force for Forrester’s research on application architecture trends, concepts, patterns, and best practices.