In performing any modernization task, there are typically four questions that must be answered: "Where am I now; what is my current as-is architecture?" "Where do I need to be; what is my target to-be architecture?" "What is the gap or differences between the two?" and "How do I get to the to-be state; what is the transition plan?"

This article describes a hybrid approach to answering these questions by using a subset of the existing Department of Defense (DoD) Architecture Framework (DoDAF) [1] views and adding an additional view to capture all the important and missing business, financial, and technical analysis information. This extension to the DoDAF is defined as the Motivational View (MV).

An enterprise's competitive edge and ultimate success are enabled by its ability to rapidly respond to changing business strategies, governances, and technologies. The DoD environment spells this competitive edge as victory. The competitive edge translates into higher levels of customer satisfaction, shorter work cycles, and reductions in schedules, maintenance costs, and development time, all resulting in lower overall costs of ownership.

Enterprise architecture is the key facilitating ingredient providing a holistic view and a mechanism for enabling the design and development as well as the communication and understanding of the enterprise. The overarching goals of enterprise architecture are to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages.

Lockheed Martin's view of an enterprise is a collection of business systems that control and manage the enterprise's functional areas. Enterprise architecture describes these systems in terms of their behaviors, methods of communications, and constraints.

Enterprise architecture enables the high-level prospective and views needed to transform as-is legacy systems of disparate stovepipe applications into the tobe set of modernized, agile, and integrated business processes. Lockheed Martin starts its enterprise architecture documentation by using a subset of the existing DoDAF views.

Enterprise architecture is documented as an organized collection of information in three divisions: driving strategies, baseline, and transition plan. The driving strategies depict goals and objectives and show the way forward, indicating where the enterprise needs to go based on business drivers, policies, rules and regulations, and advancing technology. This provides the to-be target model. The baseline is the current, as-is enterprise architecture documented in graphical models and text describing the current position in terms of organizations, business processes, information, applications, and technologies. The transition plan is the set of initiatives set to a timeline to sustain and maintain the enterprise architecture as vital to accomplishing the strategic missions of the enterprise and transition from the asis state to the to-be state.

The DoDAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture. A previous version of the DoDAF divided this list into two major categories: essential and supporting. Essential products constitute the minimal set of artifacts required; supporting products constitute information that may be needed depending on the specific drivers of the architecture.

The list of products is further refined into four views: all views (AV) and three architectural views that include operational view (OV), system view (SV), and technical standards view (TV). Briefly characterized, the AV is the overarching information describing the architecture plans, scope, and definitions. The OV focuses on the behaviors and functions describing the DoD mission aspects, both warfighting and business. The SV describes the systems and applications supporting the mission functions. The TV describes the policies, standards and constraints. The current DoDAF version indicates a subset of work products that should be developed at a minimum (essential). These include the following:

• AV-1: Overview and Summary Information.
• AV-2: Integrated Dictionary.
• OV-2: Operational Node Connectivity Description.
• OV-3: Operational Information Exchange Matrix.
• OV-5: Operational Activity Model.
• SV-1: Systems Interface Description.
• TV-1: Technical Standards Profile.

The 26 DoDAF views are designed to document the entire architecture, from requirements to implementation. What is the subset of views from the DoDAF needed to document enterprise architecture? We answer this by building on the work of Sowell [2], Brundage [3], Zachman [4, 5], and Spewak [6]. In a nutshell, the Zachman Framework is an index of architectural information arranged as a five-by-six matrix, documenting a complete architecture. Sowell and Brundage provided a mapping of the DoDAF work products onto this framework. Spewak identified the top two rows of the Zachman Framework as the significant enterprise level information. Leveraging this work collectively, we quickly arrive at a subset of eight DoDAF views that are required to represent the enterprise architecture. This subset includes the same views as listed in the DoDAF recommended minimal set plus OV-7: Logical Data Model.

Of course, this subset of eight views may be supplemented with additional DoDAF views as required by the specific needs of the enterprise architecture being developed. Still, conspicuously absent are the all-important business, financial, and technical analyses of alternatives — information needed to drive architectural decisions. How do we answer the questions of why one approach or technology was selected over another? Most significantly, how do we illustrate sound business reasons for our decisions? To remedy this, we have enhanced the DoDAF by adding the MV.

The MV draws in part from the Zachman Framework, and also includes the business metrics and investment decision models required to evaluate transition and modernization plans. In short, given the method of enterprise architecture development, in terms of strategies (tobe), baseline (as-is), and transition plan, we need mechanisms and work products to capture the trade-offs, analyses of alternatives, business metrics, financial considerations, and returns on investment to support architectural decision making; we need the MV.

What comprises the MV? Our MV includes the necessary business, financial, and investment models required to evaluate and prioritize the transition alternatives and modernization plans, thus providing a solid business foundation and rationale of why changes need to be made. These models address the issues of metrics, risks, and best value. The work products included are as follows:

• MV-1: Business Case.
• MV-2: Investment Decision Model.
• MV-3: Risk Analysis Model.
• MV-4: Best-Value Low-Risk Model.
• MV-5: Balanced Scorecard Model.

The Business Case addresses the rationale for investing the time and resources into making the necessary changes to transform the current as-is to the targeted tobe enterprise architecture. The Business Case starts with the strategies, goals, and objectives regarding how the improvements fit into the enterprise, and why they are significant. The business case also defines the all-important financial rationale measured in dollars and captured as the return on investment (ROI) and break-even time (BET).

The Business Case evaluates a variety of criteria to arrive at a business decision to make the investment required in order to perform the work necessary to gain the projected benefits. Some of the criteria used in crafting a Business Case include business strategic plan, competitive analysis, customer analysis, risk assessment, and financial factors. A sound business plan will illustrate how a reasonable one-time capital expense can achieve a significant recurring cost savings over an acceptable time period. This is the ROI and BET and is typically the driving, if not the only, reason for making changes to the existing architecture. The Business Case is a text document that includes appropriate graphics and financial spreadsheets as needed.

The Investment Decision Model provides a mechanism to perform an analysis of cost versus benefit to drive the decisionmaking process. All alternatives are viewed with regard to costs as compared with benefits. Typical considerations for cost include business process impacts, development method, integration issues, and education needs. Similarly, benefits may include increased capabilities, reduced costs, and productivity improvements.

The decision is driven by the comparison of cost to implement against the business impacts. The positive impacts realized by the business may be in the form of cost avoidance, greater market share, and/or lower risk. Based on the analysis of the supporting data, a model is generated. This model may be viewed as a four-quadrant graph (see Figure 1) labeled as follows: 1-Low Cost/High Benefits, 2- High Cost/High Benefits, 3-High Cost/Low Benefits, and 4-Low Cost/Low Benefits.

Figure 1: MV-2: Investment Decision Model

The Risk Analysis Model provides a vehicle to identify and analyze risk. Risk is viewed with regard to the probability of occurrence and impact on occurrence. This facilitates a basic three-by-three matrix to evaluate risk (see Figure 2). The table is color-coded and ranges from red to yellow to green. Red indicates high probability of occurrence and high impact on occurrence, and green indicates low probability of occurrence and low impact on occurrence.

Figure 2: MV-3: Risk Analysis Model

This is a basic view of the risk table. It may be enhanced to use percentages and/or additional categories as needed. In addition to the table, a risk-mitigation plan is typically generated for each of the identified risks, or a subset (i.e., only high) describing the contingencies when the risk occurs.

This model provides the next step in selecting the best alternatives by taking a second look at the Investment Decision Model, now comparing the best-value candidates (lowest cost/highest benefits) on the basis of risk. Risk considerations include technology maturity, numbers of interfaces, mission criticality, business process maturity, change management, and training issues. This model is typically represented as a four-quadrant graph labeled as follows: 1-Low Risk/High Value, 2-Low Risk/Low Value, 3-High Risk/High Value, and 4-High Risk/Low Value (see Figure 3).

Figure 3: MV-4: Best-Value Low-Risk Model

The Balanced Scorecard (BSC) [7] is used to provide a common standard model to manage the business and the enterprise architecture, as shown in Figure 4. The strength of the BSC is its coupling of leading (operational) and lagging (financial) indicators as well as the alignment of various enterprise capabilities. The BSC integrates various aspects of the enterprise using a set of key performance indicators (KPI).

Figure 4: MV-5: Balanced Scorecard Model
(Click on image above to show full-size version in pop-up window.)

The selection of an appropriate set of KPI is critical. The KPI should map to key business metrics, i.e., the specific measures that drive the business. Examples of these types of metrics for their industries include dollars per flying hour for the airline industry, time to process a claim for the insurance industry, and errors per source line of code for the software industry. It is critical to identify and document the appropriate metrics to use for each aspect of the BSC. These metrics become the basis for declaring success and confirming improvements such as BET, ROI, and other aspects of the business case.

The BSC relates and aligns the enterprise vision and strategy into four views: Customer View, Process View, Innovation and Learning View, and Financial View. By doing this, the model helps facilitate translating the vision and strategy into action. The four views define, describe, and capture the goals, key performance indicators, and initiatives for each of the specific area views thus providing the control and alignment needed to manage the enterprise and supporting architecture.

The DoDAF views, although adequate for describing enterprise architecture, lack the business perspective needed to develop a sound, transitional plan from as-is to tobe as required in today's architectural projects. The missing business perspective is captured via the addition of the Motivational Views, including the Business Case, Investment Decision Model, Risk Analysis Model, Best-Value Low-Risk Model and Balanced Scorecard Model. These views facilitate the business rationale and trade-offs required to develop a valid and achievable transition plan to transform the enterprise from its current as-is state to the future to-be state. The Motivational View complements the existing DoDAF views, providing a complete holistic view of enterprise architecture.

1. Department of Defense Architecture Framework Working Group. "DoD Architecture Framework Ver. 1.0." Washington, D.C.: Department of Defense, Oct. 2001 http://aitc.aitcnet.org/dodfw.
2. Sowell, P. Kathie. "The C4ISR Architecture Framework: History, Status, and Plans for Evolution." McLean, Va.: The MITRE Corporation, 1999 www.mitre.org/work/tech_papers/tech_papers_00/sowell_evolution/sowell_evolution.pdf.
3. Brundage, George. "Federal Enterprise Architecture Framework Presentation." Washington, D.C.: Department of the Treasury, July 2001 www.gsa.gov/Portal/gsa/ep/home.do?tabId =0.
4. Zachman, John A. "A Framework for Information Systems Architecture." IBM Systems Journal 26.3 (1987) www.research.ibm.com/journal/sj/382/zachman.pdf.
5. The Zachman Institute for Framework Advancement www.zifa.com.
6. Spewak, Steve H. with Steven C. Hill. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. New York: John Wiley & Sons, Sept. 1993.
7. Kaplan, Robert S., and David P. Norton. Translating Strategy into Action: The Balanced Scorecard. Cambridge: Harvard Business School Press, Sept. 1996.

1. Deming, W. E. Out of the Crisis. Cambridge, MA: Massachusetts Institute of Technology Press, Aug. 2000.
2. Hammer, Michael, and James Champy. Reengineering the Corporation. New York: Harper Collins Publishers, Inc., 1993.
3. Womack, James P., and Daniel T. Jones. Lean Thinking. New York: Simon & Schuster, 1996.

D.B. Robi is a Lockheed Martin Qualified Architecture and Certified Lean Six Sigma Black Belt. His career, spanning 19 years, has afforded him opportunities to work in both the commercial and the Department of Defense/federal sectors. Robi has performed as the lead architect on several projects as well as serving as the business architect on efforts in business process modernization, reengineering, and optimization. He is currently the technical lead for Lockheed Martin's Enterprise Architecture Center of Excellence where he leads the development and enhancement of Lockheed Martin's internally developed ARQuestsupTM/sup Blueprint Process, an approach to developing enterprise architectures. The motivational views described in this article have been incorporated and implemented in ARQuest.

Lockheed Martin Integrated Systems and Solutions (IS&S)
1801 RTE 17C
Owego, NY 13827-3998
Phone: (607) 751-7781
E-mail: dennis.robi@lmco.com