NEWS AT SEI
This article was originally published in News at SEI on: June 1, 2002
The alignment of business models and information technology (IT) architectures has been a critical issue for IT organizations for as long as IT has been an important factor in the success of organizations. Despite the near-universal acceptance of this principle, how to actually realize alignment is no clearer today than it was ten years ago. Specifically, it is not always clear when to align, what to align, and how to align. For example, when businesses encounter changes (either internal or external changes, such as business strategies, new IT products, or new legal requirements), they have to “know” whether there is any misalignment caused by the changes, have a way to gauge the misalignment, and then correct the misalignment. They have to decide in what ways, how much, at what cost, and according to what timetable the misalignment should be corrected. Since rapid change in the business environment is the only constant, the research question is: Can misalignment be prevented and, if so, how? Current SEI research has resulted in development of a method for detecting and correcting misalignment called the Business IT Alignment Method (BITAM).
Earlier research on alignment focused on defining models of alignment information and the relationships among the parts of the models. This early research was important and influential—it introduced the ideas of alignment to a wide audience and structured the space of inquiry. But it said little about how to gauge and actually correct misalignment. That was always the “magic.”
Furthermore, since 1993, when these models were first proposed, the environment with respect to IT has changed dramatically. Back then, IT functions were often a supporting role in an organization. Since the Internet revolution, IT has become critical to business success, for strategic advantage as well as for strategic and operational necessity. And IT planning has become an integrated part of business planning. With rapid technological advancements and business-environment changes, organizations are required to adapt and seek ways to continuously innovate. The older models of IT alignment were not created in this environment and are not suited for it. The strong interdependency between business models and the IT systems that realized those models was not explored in depth. In fact, the discussion of business models and processes was often completely removed from the design of the IT architecture. Earlier models address alignment issues only at the “strategic” or conceptual level of a business system. They were not able to address alignment issues down to the level of IT architecture, which is critical for alignment. Based on this background, the goals of this research are
- detection of misalignment
- to empirically categorize the types of misalignment and the types of changes that may cause each of them
- to develop a model of information required for realignment that has been tested with large IT organizations, beginning with business goals and requirements and ending with IT architectures
- correction of misalignment
- to precisely and operationally define what alignment is, and how it should be measured and managed
- to create an information model with standard means of eliciting, collecting, and organizing the information needed by the alignment/realignment process
- to consider a range of realignment strategies and have a decision procedure for choosing among the alternatives
- prevention of misalignment
- to develop processes that organizations can put in place that allow them to continually measure alignment and gauge when they are becoming misaligned. They can then take corrective measures as a continual part of their processes, rather than as a post-facto cleanup step.
This research is situated in a model of IT architectures as shown in Figure 1.
Figure 1: Business IT Alignment Model
This three-level model delineates the layers of business models, business architectures, and IT architectures. Changes may affect any of the layers, and these changes will ripple to the other layers. For example, a change in the business environment (a new competitor) may dictate that some existing business processes be changed (e.g., changes to customer relationship processes), which will in turn change the IT architecture that supports these processes (perhaps a new Web-based customer relationship management system will be integrated).
Each of these layers needs to be studied and modeled. However, simply understanding the layers is not sufficient. Misalignments are improper mappings between the layers. Realignment activities are those activities that restore coherence to the mappings. Thus, we need to characterize each of the layers as well as the mappings among them.
There are three stages of maturity in an organization’s ability to deal with misalignment. Each stage builds on the previous one. The three stages are detection, correction, and prevention of misalignments. To be able to correct a misalignment you must be able to detect it, and you must be able to gauge the extent of the misalignment and determine an effective realignment strategy. To be able to prevent misalignment, you must be able to do continual detection and correction as part of your development process.
For an organization to detect alignment problems, they need to be able to precisely characterize business goals and the relationship between these goals and IT requirements. Typically, IT organizations have no formal means of characterizing business goals. Business goals are developed and communicated in an ad hoc manner, and most IT organizations’ requirements processes are imprecise. In addition, an IT organization needs to have an established process for tracing requirements to their realization in business architectures and from there to IT architectures. These steps are necessary to be able to detect and characterize misalignment.
Once a misalignment has been detected, the organization needs techniques for characterizing the nature of the misalignment and the degree to which the three levels are misaligned. Once this characterization has been made, it is possible to consider actions that may be undertaken to correct the misalignment. But any corrective action may have consequences for any of the three levels. So any theory of misalignment or method for realignment must include techniques for
- considering a palette of corrective strategies
- comparing the various strategies, along with their tradeoffs and economic implications
- choosing the optimal strategies based on their consequences on all three levels
When selecting realignment strategies, a number of difficulties become apparent. For example, as already mentioned, it is unclear how business goals should be characterized. But correction involves many stakeholders and considerable risk. To mitigate this risk, we need to include all relevant stakeholders in the correction process. And we need to use these stakeholders to negotiate requirements and evaluate proposed solutions. Finally, we need a way to ensure that there is traceability—from business goals through to requirements through to architectures.
From Figure 1 we see that there are three alignments that we need to manage: the business model to the business architecture; the business architecture to the IT architecture; and the business model to the IT architecture. The only way to prevent misalignments is to manage these three alignments continuously, as befits an organization of high process maturity. We can do this as follows:
- We align the business model to the business architecture by creating and exercising operational scenarios that satisfy the business requirements.
- We align the business architecture to the IT architecture by exercising the same set of operational scenarios.
- We align the business model to the IT architecture by creating and exercising scenarios that satisfy the business drivers (quality attribute requirements).
We can then check the alignments in the reverse direction. Checking the alignments from IT architecture to business architecture and from business architecture to business goals involves checking that the results of exercising the operational scenarios still meet the goals of the level above. However, checking the alignment from the resulting IT architecture to the business goals is more complex. We believe that this is a process of ensuring that the IT investment strategy is fulfilled by the alignment activities. The Cost Benefit Analysis Method (CBAM) can be used to validate that the investments fulfill the organization’s business goals. .
Note that this approach is in stark contract to existing work on IT alignment, in that it proposes a concrete set of steps, each of which contributes to the creation of some measurable outcomes. While other approaches, such as basing alignment on a balanced scorecard , are useful for raising awareness of misalignment issues, they do not provide explicit guidance regarding how to measure failure or success and, more crucially, they do not aid in determining realignment strategies. The objective of our research is to do both.
Overview of the BITAM
Managing IT alignment boils down to four distinct questions: (1) How can we capture business goals (and the requirements derived from them) precisely, unambiguously, and repeatably? Additionally, how can these business goals and requirements be negotiated in an informed manner among a diverse group of stakeholders? (2) How can we document IT architectures in a manner that can be analyzed with respect to the process of alignment? (3) How can we gauge misalignment, either qualitatively or quantitatively, and how can we validate these measures? (4) How can we choose realignment strategies and prove that these strategies are optimal with respect to the organization’s business goals, including return on investment?
To realize these alignments, we have developed a 12-step method in the BITAM. The steps are as follows:
- Elicit business drivers from key management stakeholders.
- Elicit a set of operational scenarios from the entire group of stakeholders.
- Elicit a set of change scenarios from the entire group of stakeholders.
- Prioritize the operational scenarios and change scenarios.
- Elicit the business architecture from the key information architects.
- Elicit the IT architecture from the key technical architects.
- Map the operational scenarios to the business architecture.
- Map the change scenarios to the IT architecture.
- Assess the misalignments.
- Propose realignment business strategies.
- Propose realignment architectural strategies.
- Evaluate the new business and architectural strategies as investments.
These steps are evolving, but they provide a starting place from which to iteratively refine. For example, a requirements negotiation strategy has been incorporated in the method. The SEI has created a second version of the CBAM that addresses many of the problems with the initial version, primarily in quantifying uncertainty and managing the variability in stakeholder judgments. There is also a substantial body of results and experience from previous case studies. In the course of developing these methods, SEI staff have designed documentation templates for eliciting architectural information, standard sets of analysis questions, standardized approaches for dealing with the analysis of quality attributes, techniques for quantifying uncertainty, and techniques for prioritizing and validating stakeholder judgments.
Conclusions and Future Work
The BITAM holds tremendous promise for aiding organizations in managing their IT alignment processes. The BITAM is built on a foundation of road-tested analysis methods, such as the Architecture Tradeoff Analysis Method  and CBAM, and is being validated in the same fashion—through real-world case studies.
 Software Engineering Institute. Cost Benefit Analysis Method (CBAM) (2002).
 Kaplan, R. and Norton, D. The Balanced Scorecard: Translating Strategy into Action. Boston: Harvard Business School Press, 1996.
 Software Engineering Institute. The Architecture Tradeoff Analysis Method (2002).
About the Authors
Rick Kazman is a Senior Member of the Technical Staff at the SEI. His primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is the author of over 50 papers and co-author of several books, including Software Architecture in Practice and Evaluating Software Architectures: Methods and Case Studies.
Hong-Mei Chen is an Associate Professor in the Department of Information Technology Management at the University of Hawaii, Manoa. She is the founder and Director of the Advanced Information Management Solutions (AIMS) Laboratory. She has also served as the Associate Director for a large-scope, multi-institutional, high-performance telemedicine project called MISSION (Medical Imaging Support via Satellite Integrated Optical Network), and directed the design, implementation, and operation of a Web-based database system for Electrical Vehicle (EV) National Data Center for over three hundred EV member organizations nationwide. She received a B.A. from National Taiwan University and a M.A. and Ph.D. from the University of Arizona.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.