If they do it right, enterprise architects can add tremendous value to their organization's selection of a packaged application solution. The architecture \n\ninherent in any new technology acquisition can have unintended consequences, and this is especially true with a major apps solution \u2014 whether \n\nit'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 \n\ntechnology standards. Their default assumption may be that they participate in the selection process to ensure that the final selection adheres to \n\nenterprise 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 \n\nhelps 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 \n\ncompliance. Your proper contribution to a packaged apps decision is to analyze and estimate each candidate's Architectural Business Value (ABV), \n\nwhich Forrester defines as: The estimated Total Economic Impact (TEI), for a candidate solution, of: 1) ongoing costs incurred for process, organizational, and technical \n\nadaptations required because of a solution's divergence from IT standards; and 2) ongoing benefits created by the solution's comparative architectural \n\nstrengths vis-\u00e0-vis other candidates.Educating the selection team on the concept of ABV is your first challenge. From there, across the four phases \u2014 organize, narrow, evaluate, \n\nand decide \u2014 of the selection process, you will build initial ABV models, identify key factors that will affect ABV, test key factors and document \n\ntheir 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 ProcessAs 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: \n\nEstablish your business credibility. Make it clear that your goal is business analysis, and that your technology analysis is only for the \n\npurpose 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 \n\ncosts, 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 \n\nABV 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 ModelDuring the Narrow Phase, your goal is to identify, in priority order, the most significant factors that will contribute to the ABV of each shortlist \n\ncandidate. Your assessment of the value of architectural strengths should be driven primarily by connecting these strengths to business strategies and \n\nobjectives, 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 \n\nimpactful 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, \n\nprovide 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 \n\norder-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, \n\ncatalog the ABV factor differences among the shortlist, ignoring factors that are equivalent. Then, starting with those likely to have the biggest impact, \n\nbuild a model for the detailed ABV analysis to be done in the Evaluate Phase. During The Evaluate Phase, Complete Your ABV AnalysisTo 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 \n\nfairly claiming support for your standards. Assume that you won't have sufficient time to analyze every major ABV factor, so proceed in priority order, \n\nstarting 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), \n\nconduct 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 \n\neach 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 \n\ntest, do paper-based analysis. What new IT operations procedures will be required? Will non-standard technologies require the organization to hire new \n\nstaff (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 \n\nyour 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 \n\nflexibility aspects of your ABV analysis. During The Decide Phase, Support The Overall Business Value WinnerOnce 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 \n\nbusinessperson: 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. \n\nBusiness executives distrustful of IT often want the fastest path to any solution. Application delivery teams with project deadlines to meet are often \n\nimpatient with architectural restrictions. As enforcers of IT standards, architects often prioritize consistency above business value. For many types of decisions involving business \n\ntechnology architecture, Architectural Business Value allows architects to reframe discussions away from architectural standards toward the bottom \n\nline of the business. It won't eliminate politics, but it can reduce them while building credibility for architects as businesspeople, which they should be, \n\nanyway.Randy is Vice President, Principal Analyst at Forrester Research. He is a leading expert on architectures and design approaches for building \n\nenterprise applications that are secure and resilient in the face of continuous business and technology change. This makes service-oriented \n\narchitecture (SOA) one of Randy's primary focus areas. Since enterprise applications need much more than SOA, Randy led the development of \n\nForrester's Digital Business Architecture, which provides a broad architectural context around SOA. For seven years, Randy has been a driving force for \n\nForrester's research on application architecture trends, concepts, patterns, and best practices.