Planning is critical for achieving a useful enterprise architecture (EA). Key to remember is that EA is a decision support tool, not an end unto itself. To achieve success, you need to have a good understanding of the decisions stakeholders make and the data needed to support this decision-making.

There are two parts to architecture planning: identifying the scope of the architecture work, and planning for the project or projects to do this work. This chapter focuses on aspects of planning the architecture work, specifically scoping the architecture work.

An enterprise is dynamic and continuously evolves in response to business and technology drivers. Thus, the EA must be an evolutionary document driven by stakeholder decision-making needs and priorities. The architecture is developed in an iterative manner, with each release being responsive to priority decision-making needs and providing data in a timely manner. This means that planning for the architecture, especially scoping the work, is also an iterative process.

The architect needs to identify stakeholders (users of the architecture) and work with them to identify their needs and priorities. The top priority issue or set of related issues drives the initial EA release(s), while a priority organized backlog of issues needs to be maintained as input to the next planning iteration. Managing the scope of each architecture release is critical. Attempts to develop an architecture in one large project and without proper attention to stakeholder needs and priorities tend to result in an expensive and unmanageable mountain of data that stakeholders have no idea how to use.

We use the DoDAF Six-Step Process, described in Chapter 4, to guide our architecture planning process, as this is the general process associated with the defense-related frameworks. Other comprehensive and relatively more prescriptive approaches, such as the TOGAF Architecture Development Methodology (ADM) and the FEAF2 Collaborative Planning Methodology, both discussed in Part IV, cover similar topics.

Figure 5-1 shows the Six-Step Process from the planning perspective. Steps 1, 2, and 3 and part of step 4 need to be performed to scope the architecture work for a given architecture release and are the focus of this chapter. This part of planning needs to be done prior to developing or issuing a statement of work (SOW) for architecture development. Planning for the rest of step 4 and steps 5 and 6 is part of planning for an architecture development project and is addressed in Chapter 6.

Figure 5-1   The Six-Step Process from a planning perspective

Since EAs evolve over time, the work identified in the scoping process may be addressed in more than one project. The approach to breaking up the EA work into projects (selecting among the needs and priorities of the various enterprise tribes) and the approach to planning in general is driven by enterprise culture.

Scoping the Architecture Work

The first few steps of the Six-Step Process identify what needs to be done in terms of the scope and deliverables of an EA release, as illustrated in Figure 5-2. The goal of the planning exercise is to establish traceability from the stakeholder-selected issues driving the EA release to the selected architecture artifacts and the data that they contain. This traceability ensures that the architecture release contains the data needed to support the stakeholders’ decision-making in a timely manner, based on enterprise priorities. This traceability also provides a useful communications tool for getting stakeholder support for the architecture as it shows directly how the architecture will be useful.

Figure 5-2   Scoping the architecture work

The information developed in these first few steps also includes information needed for the DoDAF Summary and Overview Information (AV-1). We review each of the first four steps of the Six-Step Process in detail in the following sections, provide examples, and summarize success factors before moving on to planning for an architecture development project in Chapter 6.

Purpose

Step 1 of the Six-Step Process focuses on identifying the reasons why the architecture release is being developed. Figure 5-3 lists some common items that need to be considered. Identifying the purpose of the architecture involves both framing the high-level problem or issue that the architecture release is being built to address as well as identifying all the users of the architecture release and their specific questions and time constraints. Identifying the high-level problem serves to align the architecture with strategic business or mission needs, while identifying the stakeholders and their specific questions ensures that the data needed to address specific decisions is included in the architecture release with the right level of detail. The architecture stakeholders considered here go beyond the usual set of stakeholders considered in system development, because a wide range of decision-makers in addition to system or even business process sponsors, owners, or users may use the architecture information in decision-making processes.

Figure 5-3   Determining the intended use of the architecture

The material developed in step 1 will drive the selection of data and artifacts for the architecture, the level of detail needed, and completion criteria for the architecture. For example, a common problem is deciding how far to decompose an activity model (DoDAF OV-5). A typical question that architectural modelers often ask is, “We’ve decomposed the activity model down five levels. Are we done?” The answer depends on the intended use of the information, based on the specific needs of stakeholders. Suppose the architecture purpose is to develop an understanding of the current operations of an organization’s headquarters offices. This information will be needed to perform impact analysis for proposed changes. Then the activity model needs to decompose organizational activities down to the level where the activities performed by the headquarters offices can be separated from the activities performed by other organizational entities, regardless of the number of modeling levels involved.

Identifying the High-Level Purpose

The development of an architecture is normally driven by some important business need related to strategic business goals and objectives. The architecture usually supports some combination of transition planning and analysis. For example, in the case study (Chapter 3), the architecture supports transition planning and helps keep the changes and investments aligned with strategic goals.

Business transformation in the commercial world [KPMG 2017] is based on transforming the business model (such as managing revenues) or transforming the operating model (such as managing costs). An additional transformation that today is becoming an essential one is technology and infrastructure model transformation. The technology and infrastructure model serves not only as an operating platform in the traditional manner, but also connects the enterprise to the markets and customers, and provides a competitive advantage. Transforming the business model involves looking at markets, brands or business propositions, and customers. Transforming the operating model entails looking at core business processes, operational infrastructure and technology, organizational structures, governance and risk controls, people, and culture. Figure 5-4 shows the various types of transformation with the factors that must be examined.

Figure 5-4   Transformation target types

The technology and infrastructure model in its own right provides both a platform for the operational model and competitive differentiators in the business model. Adoption of disruptive technologies can afford competitive advantage on the one hand and self-disruption on the other.

Transition planning drives transition of the enterprise from the current (as-is) state to the desired target (to-be) state. Typically, two architectures are built: an as-is and a target architecture. Gap analysis between the target and the current states will provide clarity on the changes to be made. A transition plan or roadmap involves transformation of architecture elements from the as-is state to the target state. The transition plan will indicate what architecture elements will be deleted, which will be carried forward, which will be transformed or modified to be consistent with the target state, and when and how the transformation will take place. Typical examples of strategic changes that drive the need for transition include new capabilities, innovations, mission/business process reengineering, modernization, reorganization, and mergers and acquisitions.

Additional business needs that require architecture analysis include selection of projects for funding, joint/mission interoperability, and legacy system integrations. When multiple competing projects are requesting funding, determination of importance, “fit,” priority, and continued longevity within the business context can be accomplished by building an architecture within which the competing projects can be compared and their relative impacts analyzed.

Joint or mission interoperability in defense enterprises is key to the operation of joint task forces. In the commercial world, mission interoperability is key to successful mergers and acquisitions as well as to consolidations or downsizings. Joint operations involve coordinating activities from multiple organizations with different processes, skills, training, operational structures, and organizational cultures. Mission interoperability requires “threading” together activities from these multiple organizations. Having architectures depicting the operational activities for each of these organizations is useful to support the definition of these mission “threads” and to ensure that data and information can pass seamlessly across organizational interfaces.

Integration of legacy systems is frequently a part of other types of enterprise changes such as mergers, acquisitions, and business process reengineering. Legacy systems are information systems implemented in technologies that are either obsolete or becoming obsolete but that continue to exist because the business value these systems provide cannot be provided easily or conveniently with newer systems built on more contemporary technologies. Integration of legacy systems involves orchestrating a set of system functions, some belonging to the legacy system and others belonging to newer systems. This orchestration also touches platform interactions, data exchanges, and connectivity issues as well as timing- and execution-related parameters. An architecture description depicting the legacy and new systems in a common way allows for the depiction of these issues and provides a means to achieving successful orchestration.

The high-level problem driving an architecture release may also involve at least one of the following: specific strategic objectives, key tradeoffs, critical issues, critical decision points, or specific analyses. An example program strategic objective might be a capability improvement, such as increasing the overall efficiency of a mission process by a certain percentage or improving the quality of the process output. An example of a strategic objective for the Federal Aviation Authority (FAA), for example, is to increase air traffic three times. The Next Generation Air Traffic System (NGATS) Architecture is being built both to guide transition and decide the appropriate measures for air traffic. An example key tradeoff is the one between centralized data management and distributed, replicated data with the synchronization management issues it entails. This tradeoff is frequently a key issue with the intelligence community. The tradeoff involves both operational issues regarding which approach best supports operations and technology issues regarding the current technology support for data replication and synchronization. An example critical issue is air defense command and control in the context of a joint task force. Since any of the military services may staff the air defense position in a joint task force, the solution must allow flexibility for the different services’ approaches to this process.

Each problem may involve specific analyses of architecture information or analyses to which architecture information provides critical input. For example, answering questions about process improvement may involve activity-based costing analysis that will require both architecture information, such as an activity model, and financial/cost information. Support for selection of projects for funding may involve business case analysis. Tradeoffs may require performance modeling or simulation.

The Challenges of Transition

Any change can be disruptive. Many types of changes create ripple effects, impacting areas of the enterprise that do not initially seem involved. Gap analysis supports impact analysis, enabling the identification of all the potential disruptions so that they can be anticipated and dealt with successfully. Changes that impact enterprise culture, such as mergers, acquisitions, or reorganizations, and enterprise tribal cultures, such as changes that impact a specific tribe’s activities, roles, skills, or responsibilities, are most difficult to address. These cultural changes need to be identified early and managed carefully since they may result in fierce resistance unless management gets buy-in from the impacted stakeholders, regardless of the technical merits of the intended change.

Many large federal government “modernization” initiatives at the Internal Revenue Service, the Securities and Exchange Commission, the United States Air Force, and other agencies have failed for a variety of reasons, all of which involved cultural issues. Over time, a particular system or way of doing business becomes integrated into the culture, and attempts to change it are met with resistance and lack of will to change.

Part of transition planning includes an impact analysis of the planned changes on the enterprise and its organizations, locations, work force, business processes, systems, and infrastructure.

Identifying Stakeholders and Their Issues

Although there is usually a single high-level purpose for building an architecture release, there are usually multiple users of the architecture, or stakeholders, with each having unique expectations of what the architecture will do for them. Each of these stakeholders has specific purposes for the architecture: decisions they need the architecture to support and specific issues and questions that they want the architecture to address. Not only are there multiple stakeholders with multiple purposes and time constraints, but many times these purposes are in conflict with one another. It is important to identify all the stakeholders and to address conflicts among the purposes. Stakeholder needs may have to be prioritized in the face of resource constraints in developing the architecture release. Reconciliation of multiple stakeholder needs into a single set of purpose statements for the architecture may involve tradeoffs and compromises.

Determining the full set of stakeholders and their architecture purposes may require detective work, some of which involves identifying the relevant “informal” enterprise tribes, as discussed in Chapter 2. Internal enterprise stakeholders entail all architecture users including the architecture owners and the organizations sponsoring the architecture work. However, in government or large organizations, success in achieving the owning organization’s goals may include satisfying the needs of external architecture user groups, as illustrated next.

One way of identifying internal stakeholders is to consider the levels of stakeholders by function as identified by the key abstract roles described by the Zachman Framework (see Chapter 21). Figure 5-5 summarizes the top level of these types of stakeholders.

Figure 5-5   Levels of stakeholders from the perspective of the Zachman Framework (graphic from the DoDAF)

In defense enterprises, as in every other enterprise, there are often important external stakeholders. It is important that you consider the various levels of governmental decision-makers who may be using the architecture. For example, in DoD, the owning organization may need the architecture to address a service-specific program objective, but the Joint Requirements Oversight Council (JROC), which approves program funding, needs the architecture to determine how the proposed solution supports DoD-wide capability improvement goals and objectives. Additional architecture users would include service-specific investment/budget decision-makers, Battle Integration Laboratories, and service training organizations. Architecture users also include the groups that will perform the analysis of the architecture information. Figure 5-6 illustrates the various levels of stakeholders who may be involved with a DoD architecture.

Figure 5-6   Levels of stakeholders for DoD within the government

The high-level stakeholders, such as the Government Accountability Office (GAO) and Office of Management and Budget (OMB), identified in Figure 5-6, also need to be considered for non-DoD federal departments, since the financial governance and legislative oversight is the same for all federal departments and agencies. OMB has very specific requirements regarding the architecture information it needs before it will approve funding for projects. (For example, see the “Enterprise Performance Life Cycle Framework” overview document published by the Department of Health and Human Services, at www.hhs.gov/sites/default/files/ocio/eplc-lifecycle-framework.pdf.)

For both government and commercial organizations, external partners may also be stakeholders. For example, working out details of “just-in-time” delivery of parts or supplies will involve joint architecture analysis and agreements between manufacturers and their suppliers. Similarly, commercial enterprises need careful architecture analysis to support agreements with any outsourcing partners to ensure security, privacy, and data ownership issues, among others. These arrangements are becoming increasingly important with the advent of the cloud.

Government organizations may need to work with commercial organizations or international partners. For example, the FAA needs to coordinate with the corresponding agencies in many countries and with international aviation organizations as well as with commercial airlines. The Treasury Department needs to coordinate procedures with commercial banks and the Federal Reserve System. The Securities and Exchange Commission accepts fees and filings from regulated companies. Additional discussion of stakeholders is found in Chapter 7.

A useful artifact for tracking stakeholders, their concerns and constraints, and the views that will be used to document the architecture data needed in response to their concerns is a stakeholder matrix. This type of matrix is useful not only for planning, but also for getting buy-in from stakeholders, because the matrix can be used to show the value added by the architecture to a stakeholder’s decision-making. Examples of the planning version of the stakeholder matrix are included in the examples at the end of this chapter. A slightly different form of the stakeholder matrix can also be used to track the political issues associated with the stakeholders and each stakeholder’s importance to success of the architecture effort. This form of the stakeholder matrix is discussed in Chapter 6.

For RMN Airport, the types of stakeholders are identified in the references. Figure 5-7 shows an example set of stakeholder types. During a specific project activity or while architecting a segment of the airport, this taxonomy is instantiated with specific players or organizations.

Figure 5-7   Potential stakeholder types for RMN Airport

Scope

While step 1 of the Six-Step Process identifies the purposes of the architecture release, step 2 sets the scope of the release. The scope determines what is considered internal to the architecture release and what is external. Scope includes the level of the architecture (enterprise, segment, or solution), mission or organizational boundaries, technology and time frame constraints, and other scoping issues. (See Chapter 23 for a standard list of enterprise scopes as defined by the Federal Enterprise Architecture Framework Version 2 [FEAF2].)

Frequently, an architecture release may be focused on a specific aspect of a larger enterprise. Step 2 determines how to decide whether specific information should be included in the architecture. This step is critical to keeping the architecture release focused and ensures that the resulting architecture is developed in a timely manner to support decision-making.

Typically, the scope is determined by the context of the architecture, as summarized in Figure 5-8 and discussed in the following list.

Figure 5-8   Determining the scope of the architecture

• What’s the span of the enterprise? There needs to be a clear understanding of what level of enterprise architecture will be developed. Setting an architecture’s operational bounds starts with a clear statement of any overarching enterprise and the aspect of that enterprise that is to be the subject of the architecture. For example, within a multinational corporation, an architecture might be a segment-level architecture restricted to European operations. Within the U.S. DoD, a solution-level architecture might be specific to a single military service. Or a solution-level architecture may be part of the DoD Business Enterprise Architecture but be restricted to the Army-specific aspect of that architecture.

• What are the operational bounds? What missions, enterprise core functions, business support functions, or organizations are included? For example, within DoD, the architecture may be restricted to a specific warfare mission, to a specific support service, or to military operations other than war. Within a given operation, the architecture may be restricted to specific operational processes or to specific organizations. For example, an architecture might be limited to a specific combat service support process as carried out by a specific Army organization. For a corporation, the architecture might be limited to corporate financial operations or to a specific operation required by state law for all offices within that state.

• Are there geographic bounds? What georegions of the world, countries of the world, parts of the United States, or types of facilities and installations will be covered by the architecture effort? For example, the architecture may be focused on operations that are specific to the United States or specific states or territories, or it may involve worldwide operations. Some architectures may be restricted to a specific country or international geographic area, such as the Middle East, Africa, or Southeast Asia. A defense architecture may be restricted to in-theater operations. An architecture may have more generic geographic limits such as land, sea, littoral, air, or space.

• What time frames does the architecture address? The time frame for an architecture release is the range of dates for which the architecture applies. A current, objective, or as-is baseline architecture documents the current state of the enterprise and can be used to support decisions having to do with sustainment. Sometimes these architectures are called “as-planned architectures” if they include information on the changes that are planned and funded within the current budget cycle. “Target” or “to-be” architectures address the anticipated architecture of the enterprise at some future point in time. To-be architectures need to have a specific date attached that indicates when the architecture is expected to become the as-is state of the enterprise. An enterprise may have multiple to-be, phased, architectures that show transitional stages toward a target or vision architecture. For example, a vision architecture is used to support strategic decision-making for the longer term, while the to-be architecture for the next budget cycle documents the proposed improvements to the current architecture for which funding is being sought. This near-term to-be architecture should be achievable within the fiscal years covered by that next budget cycle. These transitional architectures typically contain varying levels of information and detail. The vision architecture may focus only on high-level concepts, while the to-be architecture for the next budget cycle needs to be very detailed and concrete. The budget cycle to-be architectures should move the enterprise in the direction of the current vision architecture. The vision architecture will itself evolve over time to reflect changes in business strategy and technology.

• Are there constraints on the technology to be considered? The scope should identify any assumptions and constraints on the technology aspects of the architecture. As-is architectures may be limited in the extent of the information technology (IT) considered. The architecture may focus on applications only, or it may include infrastructure aspects of the technology, such as platforms and communications. Sometimes an as-is architecture may simply consist of a technology inventory. To-be architectures may be limited in terms of specific technology assumptions and constraints. Near term to-be architectures may need to be limited in the technology included by the need to remain interoperable with a specified set of external legacy systems or standards. Enterprise policy may limit technology for some parts of the enterprise, such as business operations, to available commercial-off-the-shelf (COTS) technology. Other parts of an enterprise may expect the use of innovative technology to meet operational capabilities. For example, the Internal Revenue Service (IRS) needs to restrict its operational IT to COTS technologies that have the proven capability to handle large amounts of data and transactions, while the intelligence community usually has requirements that “push the envelope” and will necessitate innovation in terms of integration of COTS or development of new algorithms and solutions.

• Are there specific schedule and resource constraints? For an architecture release to be useful, it must provide information in a timely manner to a prioritized set of stakeholders. This means that there will be schedule constraints on the completion of the release or at least on the completion of some set of views in the release. For example, specific enterprise milestones may need to be met. Architecture guidance for key system development projects may be needed by specific dates (driven by the system development schedule), or other types of architecture information may be needed in time for an annual investment review at a specific time of year. In addition, there are always constraints on the resources available for the development of the architecture. There are usually budgetary constraints that limit the level of effort available to meet the architecture requirements based on identified milestones or schedules. These schedule and resource constraints make it important to focus the scope of the architecture carefully to get timely and useful results. Given the schedule and resources constraints, other aspects of the architecture scope, such as operational and geographic bounds and time frames, may need to be revisited and stakeholder priorities reconsidered. For example, the operational bounds of the architecture may be further restricted to the operations supported by the system or systems for which architecture guidance is needed. Stakeholder issues that cannot be addressed in the current release need to be added to a maintained backlog and reconsidered for the next release.

Identifying Needed Data Types

Step 3 focuses on identifying the types of data needed to address the architecture purposes and stakeholder questions, within the bounds of the architecture scope and without explicit consideration of which architecture views or artifacts will be used to document the information. Figure 5-9 summarizes the focus of this step. To identify the needed types of data and their relationships, each purpose or stakeholder question should be examined to see what types of architecture data are needed to address the problem or answer the question and how these types of data are related. The concepts and relationships introduced in Chapter 4 provide a basic set of data types and relationships that can be used.

Figure 5-9   Determine the data required to support architecture development

Sometimes the stakeholder questions may be too high-level or complex to analyze directly. In this case, each high-level question must be decomposed into a set of simpler questions whose answers provide the architecture information needed to address the original question. Further, not all the types of data needed by a purpose or problem are architectural in nature. For example, questions involving cost may need substantial financial input, and most financial information is not usually captured in an enterprise architecture.

A specific example of a question involving cost is determining the return on investment (ROI) for a proposed project. ROI analysis is frequently used in answering questions having to do with selecting projects for funding. The type of data needed to calculate ROI includes the cost of current operations, cost of the change process, and cost of the reengineered operations. The architecture inputs to this calculation are the details of current operations (as-is activities and systems support), the phasing of changes (new business process and system availability timelines), and the details of the reengineered operations (to-be activities and system support). The architecture would not usually include the salary data or facility cost data that is used to calculate operational costs. This financial data would have to come from a different source such as Human Resources or a financial planning group. However, the architecture could include information on the staff size and skills (roles and skills of performers in organizations) needed for current and reengineered operations. The architecture could also include summary information on operations and maintenance costs for the automated support for operations. The architecture could also include the performance measures used to evaluate the efficiency of the business process, the values of those measures for the current process, and the goals for the values of those measures for the reengineered process. So, the following types of data, at a minimum, are needed to answer questions about ROI: as-is and to-be business process activities, their supporting systems, to-be business processes and supporting systems availability timelines, as-is and to-be roles and skills required by performing organizations, and performance measures that relate to the activities and processes.

Performance measures are one type of data that should not be overlooked. Many architectures have as a purpose the improvement of some business process or business outcome. For U.S. government departments and agencies, the Office of Management and Budget (OMB) guidance requires performance measures to be associated with mission outcomes. Some guidance on performance measures can be found in the Federal Enterprise Architecture Performance Reference Model (PRM), which is part of the Consolidated Reference Model. The PRM has a standard taxonomy for classifying types of performance measures and advice for creating a “line of sight” from improvements in IT performance to improvements in business outcome performance. Performance measures can be associated with (related to) capabilities, business processes, or systems and services. Note that the performance measures included in the architecture are not the management performance measures applied to an architecture development project.

It is very important to determine the data needed up front prior to jumping into the architecture effort. By determining what is needed—and, more appropriately, what is not needed—the architecture team can focus on collecting needed data and developing useful architecture artifacts or views. The planning examples at the end of this chapter show stakeholder questions and their corresponding required data and relationships.

Determine What Views to Use: How to Organize and Correlate Data

From the perspective of scoping the work, we limit our consideration of step 4 activities to determining how to organize and correlate the types of data identified in step 3. In planning, the architect selects views that cover the needed types of data identified in step 3. These views are usually selected from an integrated set of views and modeling techniques based on a corporate methodology or a standard framework such as the DoDAF. The development organization’s specific architecture development process guides the modeling techniques to use and the order in which the views are built. The specific architecture development process also guides the tools and data storage approach used. The sets of views used to organize and correlate data usually use mathematical modeling techniques and the framework ontology to ensure that the data collected is consistent, complete, and correctly correlated in the structured knowledgebase or architecture repository.

In the following discussions and examples, we use the DoDAF-described views organized in the DoDAF set of viewpoints as our integrated set of views from which to choose. Note that the DoDAF doesn’t require that the views described in it are used to develop the architecture; it just requires that the needed data (from step 3) be represented in those standard view formats for sharing among DoD architects. In this way, DoD architects don’t have to learn everyone else’s methodologies and models to understand shared DoD architectures.

Figure 5-10 summarizes all the activities to be accomplished in step 4. The activities covered in this section are marked with asterisks.

Figure 5-10   Organize and correlate architecture data

Planning activities in step 4 complete the traceability from architecture purpose and stakeholder questions to the architecture data needed to answer the question to the views needed to capture that data and ensure it is consistent and complete. This traceability ensures a useful architecture with integrated views and data. Figure 5-11 illustrates the importance of establishing this traceability to the development of a useful architecture.

Figure 5-11   Traceability to stakeholder needs ensures useful architectures.

Many people jump straight to step 4 when planning an architecture and end up wasting time and effort. They spend resources on false starts and in building views that are not useful because they are not related to stakeholder (decision-maker) needs. Any time spent in performing steps 1 through 3 is more than made up for by the improved and more complete decisions made in step 4. These better decisions, in turn, ensure useful architecture results.

The process of selecting views is not a simple step. The architect must select the appropriate viewpoints and views together with the options and tailoring needed for each view. Each of these steps is discussed in the following sections.

Selecting Viewpoints

The DoDAF organizes its views into a set of eight viewpoints, as discussed in Chapter 4. While the All View (AV) products are always included in an architecture, the inclusion of other viewpoints are determined by the types of data identified in step 3. As an architecture evolves and matures, additional viewpoints and views may be added. It is not necessary to build all the views in the same release.

As an enterprise initiates its architecture efforts, the viewpoints needed may be limited, depending on the immediate needs of the enterprise as reflected by prioritized stakeholder questions and issues. For example, an enterprise’s immediate need may be a better understanding of its current operations. Fairly newly formed organizations, such as the Department of Homeland Security (DHS), may need to start with the Operational Viewpoint. An older enterprise’s immediate need might be to gain control over its technology inventory in order to manage software licensing problems. Such enterprises may need to start with the Systems Viewpoint, although the Systems Viewpoint’s view links to Operational Viewpoint views must remain to-be-determined (TBD) in the initial architecture release. Other enterprises may decide to focus early architecture efforts on interoperability issues. These enterprises might start with a Standards Viewpoint. In this case, the Standards Viewpoint’s view links to Systems Viewpoint products must remain TBD until the Systems Viewpoint is developed. Any of these enterprises may include a Capability Viewpoint or Project Viewpoint to provide a basis for focusing new projects on strategic needs.

Selecting Views

In general, you want to select views to address the types of architecture data identified in step 3. However, because there are many potential DoDAF views to pick from, we provide some general guidance on where to start. For each of the levels of architecture (enterprise, segment, and solution), we have identified a set of core views that we recommend for that level. The core views for a given level of architecture are the basic set of views that we recommend architectures at that level include. Each of these sets of core views is presented next together with its rationale.

Enterprise Level Architecture Core Views   The Enterprise Level architecture goal is to provide traceability from the enterprise strategic vision, goals, and objectives to the capabilities needed to achieve those objectives and to the projects (and their managing organizations) that implement those capabilities and to the organizations that use the capabilities. Phasing and timelines are a key part of this traceability. The core set of views for Enterprise Level architectures follows:

• AV-1: Overview and Summary Information

• AV-2: Integrated Dictionary

• CV-1: Vision

• CV-3: Capability Phasing

• CV-4: Capability Dependencies

• CV-5: Capability to Organizational Development Mapping

• PV-1: Project Portfolio Relationships

• PV-2: Project Timelines

• PV-3: Project to Capability Mapping

• OV-4: Organizational Relationships Chart

These views are primarily from the Capability and Project Viewpoints and support the type of basic information that is needed for Enterprise Level decision processes such as portfolio management and investment management. Figure 5-12 illustrates the integration of these core views for Enterprise Level architectures.

Figure 5-12   Integration for Enterprise Level architecture core views

Segment Level Architecture Core Views   A Segment Level architecture may manage a subset of capabilities from an Enterprise Level architecture as well as coordinate the set of solution architectures that will provide those capabilities. Thus, Segment Level architectures may have the characteristics of both Enterprise Level architectures and Solution Level architectures. If the Segment Level architecture is to be used for investment management or portfolio management for the capabilities included in the segment, then the core views for the segment should include the same views identified as core for an Enterprise Level architecture. In the case of a Segment Level architecture, those core views will be restricted to the subset of capabilities, projects, and organizations that fall within the scope of the segment. If the Segment Level architecture is to be used to coordinate a set of Solution Level architectures, then the core views for the segment should include the same views identified as core for a Solution Level architecture. However, in the case of a Segment Level architecture, these views will be focused on providing business context, documenting the support of the systems to the high-level business processes, and documenting business process and system interfaces necessary to ensure interoperability across the systems in all the solution architectures within the scope of the segment.

In addition to views, reference models (RMs) may also be included or associated with architectures. Enterprise Level and Segment Level architectures may use the various types of RMs to provide consistency and continuity of vocabulary and content across all the related Segment and Solution Level architectures. For example, a business reference model (BRM) can be used to further define the business areas and missions included in the scope of the enterprise. Each related Segment and Solution Level architecture can identify its relevant sets of business areas and missions. Enterprise and Segment Level architectures can use a technical reference model (TRM) to define the superset of standards that will constrain and help define the standards included in all the related Solution Level architectures.

Solution Level Architecture Core Views   The goal of a Solution Level architecture is to provide traceability from performers to the operational activities they perform and to the IT that supports those activities. The resources or information exchanged is a key part of this traceability. The core set of views for Solution Level architectures follows:

• AV-1: Overview and Summary Information

• AV-2: Integrated Dictionary

• OV-1: High-Level Operational Concept Graphic

• OV-2: Operational Resource Flow Description

• OV-3: Operational Resource Flow Matrix

• OV-5a: Operational Activity Decomposition Tree

• OV-5b: Operational Activity Model

• SV-1: System Interface Description

• SvcV-1: Services Context Description

• SvcV-4: Services Functionality Description

• StdV-1: Standards Profile

• CV-6: Capability to Operational Activity Mapping (optional)

The core set for the Solution Level architectures includes different options depending on which of the Systems or Services Viewpoints is included. (If the as-is portion of a solution architecture uses the Systems Viewpoint and the to-be portion of the Solution Level architecture uses the Services Viewpoint, then both sets of views will be included in the overall architecture.) The Services Functionality Description is included if the Services Viewpoint is used.

The integration of these core views is well defined, as illustrated in Figure 5-13, which shows only the Systems Viewpoint core view (instead of both the Systems and Services Viewpoints core views). The Capability To Operational Activities Mapping is not included in the figure because it is optional and should be included in the Solution Level core set only when the Solution Level architecture has an overarching Enterprise or Segment Level architecture that includes capabilities.

Figure 5-13   Integration for the Solution Level architecture core views

The views that are not designated “core” for the Solution Level architecture are sometimes called “supporting” views. The supporting views are included in the architecture as required by the purpose of the architecture.

General Guidance on Selecting Views

For each needed viewpoint, build the core views for the appropriate level of architecture. These views cover the information commonly needed in that level architecture and provide commonality needed for comparisons across architectures developed by different organizations. If any needed data from step 3 is not addressed by the core views, select supporting views that cover that data—that is, select appropriate additional views that are not included in the core set for the given level architecture. Some corporate methodologies or government regulations, such as DoD directives, may require certain of the supporting views.

To select supporting views, you need to know the information addressed by or covered in the view. The three critical aspects of this information are the view template that provides the format for the view’s graphic component, the information required by the dictionary entries for the view, and the view options. This information is covered in Part III of this book.

As an example, Table 5-1 provides a list of the views that are “supporting” for Solution Level architectures. Because the DoDAF view numbers are strictly arbitrary, this list is organized into categories that may help in selecting views. (More detail on these views is provided in Part III of this book.) However, some Capability and Project Viewpoint views listed may not be appropriate for a Solution Level architecture. For example, the Project Timelines view (PV-2) is designed to compare and relate project timelines over multiple projects. It is not appropriate to use PV-2 for one project. The timeline for a specific project by itself is of interest only to the immediate project management and sponsor and is part of the program management plan. The Project Timelines view is to support coordination and management of multiple projects.

Table 5-1   Supporting Views for Solution Level Architecture, by Category

If additional needed data cannot easily be addressed by any standard DoDAF views, even with tailoring, you may need to add Fit-for-Purpose views that are not included in the set of DoDAF views. Other frameworks, such as The Open Group Architecture Framework (TOGAF) and the Federal Enterprise Architecture Framework Version 2 (FEAF2) may be useful sources for additional types of views. (In addition, other defense frameworks related to DoDAF are relevant here. These include the MODAF [Ministry of Defense Architecture Framework] and NAF [NATO], which are now being merged. See Part IV for details about these other frameworks.) Additional views may range from reports based on information already captured in the dictionary (AV-2) to complex models for executable architectures. You may choose to include some additional Fit-for-Purpose views, such as dashboards, pie charts, bar charts, or fusion diagrams that draw on the data developed by more formal views and present that data in a form that supports the specific needs of decision-makers. In other words, the views used by architects may not be the best format for presenting data to decision-makers.

Added Fit-for-Purpose views should be documented in the Overview and Summary Information (AV-1). This documentation includes a discussion the semantics of any graphic notation or a reference to readily available texts or web sites that discuss the new view. In addition, the data to be included in the added views will need to be identified for inclusion in the dictionary (AV-2), and the relationship of the Fit-for-Purpose view to the standardized DoDAF views will need to be defined. The resulting set of views needs to remain integrated.

Planning Examples

Following are some examples of the results of applying the previously described planning process to architectures at each architecture level. These examples are based on the case study in Chapter 3 of this book. The view examples in Part III of this book relate to these three architectures.

Enterprise Level Architecture Planning Example

Here is an example of the documentation resulting from planning for an Enterprise Level architecture, based on the case study in Chapter 3.

Purpose   Provide guidance on what additional capabilities/business services will be necessary to achieve RMN Airport’s strategic goals of becoming a viable alternative to LAX. The initial phase of the architecture will document the current baseline and starting point for any transition plan.

Stakeholders   Port Authority (especially the Planning Committee), RMN management.

Stakeholder Questions and Issues   The members of the appropriate county Port Authority Planning Committee have the following questions:

• What business services do we currently offer?

• Do these business services have any dependencies or relationships?

• How are these business services grouped into segments for management purposes?

• How do the current business services relate to the RMN Airport strategic vision and goals? That is, how important will the current business services be to achieving our strategic goals?

• What project/programs or contracts do we have that provide these business services, and what organizations oversee these projects or contracts?

• What organizations use the business services?

• When does the current funding for the existing projects/contracts expire? That is, for how long have the funds for these projects/contracts been committed?

• What are the current performance measures and values?

Scope

• Enterprise Level architecture for RMN Airport

• Covers all missions and organizations within RMN Airport

• Geographical bounds: RMN Airport grounds, airspace, and associated business offices

• Technology constraints: N/A (Enterprise Level)

• Time frame: As-is

Required Data and Selected Views   Table 5-2 identifies the data needed to answer these questions and the views (with selected options/tailoring) used to capture the data. There is no “stakeholder” column in this table because all the stakeholders have the same questions in this example.

Table 5-2   Mapping of Enterprise Level Questions to Required Data and Views

Segment Level Architecture Planning Example

The following is an example of the documentation resulting from planning for a Segment Level architecture based on the case study in Chapter 3.

Purpose   Passenger Management is a segment of the RMN Airport enterprise architecture. This Segment Level architecture will provide the basis for transitioning RMN Airport passenger management services over the next five years to meet RMN Airport strategic goals. The strategic goals involve the addition of new capabilities that affect passenger services.

Stakeholders   Port Authority, RMN Airport management, RMN Airport employees and unions, local county and cities, western state commuter airlines and cargo carriers/delivery services, TSA, FAA, current and potential vendors for passenger-related services

Stakeholder Questions and Issues   The following is a sample subset of the stakeholders’ questions and issues.

The Port Authority and RMN Airport management have the following questions:

• What additional passenger management business services will we need to offer within the next five years?

• What are the performance measures and their five-year goal values for all the passenger management services (both existing business services and new business services)?

• What existing passenger management business services will have to be expanded?

• What are the dependencies and other relationships among the passenger management business services (both existing and new)?

• What existing projects and contracts will be impacted by the expansion of existing passenger management business services?

• What new projects will be needed for the new passenger management business services?

• What are the major business processes that support passenger management business services?

• How many personnel will RMN Airport need to execute the passenger management business processes? What skills will these personnel need?

• What are the major systems that will be needed to support passenger-related business services in five years?

• Which of these systems will be new and which are existing systems?

• Will any of the existing passenger management systems need to be upgraded?

• What are the major interfaces among these passenger management systems with other RMN Airport segments, and with external systems?

• What infrastructure will these systems use?

• What are the standards that all the systems (new and existing) need to support five years from now?

The members of the Port Authority have the following questions:

• What passenger management business services should we offer in five years?

• Will these business services have any dependencies or relationships?

• How do these passenger management business services relate to the RMN Airport strategic vision and goals?

• What project/programs or contracts should we have to provide these passenger management business services?

• What organizations should oversee these projects or contracts?

• What organizations will use the passenger management business services?

• When do new projects/programs or contracts need to start to ensure there are no gaps in passenger management services over the next five years? Do any existing projects/programs need to be extended or upgraded?

• What are the performance measures and values for passenger management business services?

RMN Airport Management, TSA, local county and cities, and airlines have the following question:

• How many passengers can the future business processes handle per hour and per day?

Scope

• Segment Level architecture for RMN Airport

• Covers all missions and organizations related to passenger management business services at RMN Airport

• Geographical bounds: RMN Airport grounds and associated business offices

• Technology constraints: COTS, compatibility with systems in other RMN Airport enterprise architecture segments

• Time frame: To-be (present to five years)

Required Data and Selected Views   Table 5-3 identifies the data needed to answer some of these questions and the views (with selected options/tailoring) used to capture the data. This table includes a “Stakeholder” column since there are multiple stakeholders with different but overlapping questions and is an example of one form of stakeholder matrix. The table does not include all the questions.

Table 5-3   Mapping of Segment Level Questions to Required Data and Views

Solution Level Architecture Planning Example

The following is an example of the documentation resulting from planning for a Solution Level architecture based on the case study in Chapter 3.

Purpose   One of the Passenger Management Segment business services that will need to be upgraded for RMN Airport is passenger identification. This Solution Level architecture will define upgraded passenger identification business processes and provide guidance on the acquisition of the required set of applications and common databases to support these upgraded business processes.

Stakeholders   Port Authority, RMN Airport management, DHS, RMN Airport employees (IT group), passenger airlines, FAA

Stakeholder Questions and Issues   The following is a sample subset of the stakeholders’ questions and issues.

Port Authority, RMN Airport management, and DHS have the following questions:

• Will the new business processes and applications meet government regulations and requirements? That is, what types of passenger identification data is required?

• Who needs what passenger identification data and who should provide the data?

• How do the new processes improve confidence in passenger identification? (Measures include speed, availability, and consistency of data.)

RMN Airport management has the following questions:

• When will the upgraded processes and their supporting applications be ready for use?

• What performance, in terms of passengers per hour, should be expected from the new processes?

RMN Airport management and DHS have the following questions:

• How many personnel will be needed for the new business processes?

• Will the personnel need additional skills?

• When will any additional personnel be needed?

• Will new facilities be required? If so, when will they become available for use?

RMN Airport IT employees and management have the following questions:

• What are the upgraded business processes?

• How do the new applications support the business processes?

• How do the new applications, services, and databases integrate with other RMN Airport IT?

• What infrastructure will be required?

• What standards will the new applications, systems/services, and databases use?

DHS, airlines, and FAA have the following questions:

• What are the upgraded business processes?

• How do we use the new business processes and applications to get the data we need?

Scope

• Solution Level architecture for the Passenger Management Segment of the RMN Airport enterprise

• Covers passenger identification business services for RMN Airport

• Geographical bounds: RMN Airport grounds and associated business offices

• Technology constraints: COTS components and infrastructure with overall compatibility with the RMN Airport enterprise IT standards and federal (DHS/FAA) data standards

• Time frame: To-be (for 10 Year-plus time frame; includes international passenger travel)

Required Data and Selected Views   Table 5-4 identifies the data needed to answer some of these questions and the views (with selected options/tailoring) used to capture the data. The table does not include all the questions. This table is also an example of one form of stakeholder matrix.

Table 5-4   Mapping of Solution Level Questions to Required Data and Views (continued)

Success Factors in Scoping the Architecture Work

The most critical success factor in scoping architecture work is getting agreement on the purpose of the architecture. Without this agreement, the various architecture user tribes may have false expectations and various groups of architecture developers may work at cross purposes. Without a clear purpose, the architecture work may be poorly defined and produce results that are not useful to any of the architecture users. Part of getting agreement on the purpose of the architecture is finding all the users of the architecture; identifying their issues, questions, and architecture data needs; and gaining their buy-in with the changes the architecture describes.

If there is a large set of architecture user tribes with a diversity of different issues, then it is important to prioritize the groups of users and issues. It is important to focus the architecture development efforts and generate timely and useful results. Each release of the architecture can focus on an additional group of users until all are getting the information they need.

The proof of a properly scoped (and executed) architecture effort is that the architecture data is actually used in decision-making processes.

Summary

Here is a summary of advice for scoping the architecture work based on the Six-Step Process:

• Know why you are developing the architecture. Identify the full set of architecture users—the stakeholders—and the ways in which they plan to use the architecture.

• Expect to tailor the standard views to capture the data critical to your stakeholders.

• Be prepared to add to or modify the set of views as your experience with the architecture domain evolves.

• Do not develop views you can’t find a customer (a user) or a purpose for. In some cases, the architecture team itself may be the principle user of some views to support analysis, conclusions, and recommendations.

• Do not develop more detail than your architecture users need.

Questions

1. Why is it important to establish traceability from stakeholder issues to architecture data and views?

2. In your enterprise, who are the users of EA (the stakeholders) and how do they use EA information in decision-making?

3. This chapter provides suggestions for core sets of views to be included in each of the three levels of architecture. How are additional views selected?

4. Examine the views that have been selected by the partial planning analyses for the RMN Airport Enterprise, Passenger Management Segment, and Passenger Identification Solution Level architectures (Tables 5-2, 5-3, and 5-4). Have all the recommended core views been identified? Do the missing views give you any ideas for the stakeholders or stakeholder issues that might have been overlooked in the analysis?

5. The example Enterprise Level architecture for RMN Airport doesn’t include local governments and citizens as stakeholders (users of the architecture), yet these stakeholders will want information about increased noise and traffic and expansion of airport grounds and facilities to analyze for impact on their communities. Formulate some of their questions and issues and redo the analysis in the Enterprise Level architecture example to identify any additional data and views that need to be included for these stakeholders.

6. The Solution Level example in this chapter handles only a subset of the stakeholder questions. Complete the traceability table and identify the complete set of data and views needed for the Solution Level architecture. Do you see any additional questions that need to be added to the analysis? Do you see any additional data or views that can be added to the existing part of the traceability table?

7. Why is an understanding of corporate/enterprise culture and enterprise tribes important in planning an architecture to support any enterprise change?

8. Company A is a large enterprise that has decided it needs an enterprise architecture. However, management has decided not to release the architecture until it is “complete.” What are the pitfalls of this approach?

9. How might RMN Airport use the Passenger Management segment architecture in managing transition of passenger management capabilities and services? Will this Segment Level architecture be used to manage a subset of capabilities and services from the Enterprise Level architecture, or will it be used to coordinate the set of solution architectures that will provide those capabilities and services, or both? What core views should be included?

10. Here are the purpose, scope, and stakeholder questions for a Solution Level architecture. Develop the matrix to trace the questions to the data types needed to answer the questions and to the views (with options and tailoring) to develop and document the required data. Reference Chapter 4 of the text for more information on views.

Purpose: Define the operational processes and IT necessary to support data sharing for a newly formed cross-agency security incident management community of interest (COI).

Scope

• Cross-agency Solution Level architecture

• Function: Airspace security incident management

• Geographic: CONUS but coordination needed with internationals

• Time frame: To-be 2020

• Technology constraints: COTS integration; must integrate with existing agency systems

Issues and Questions

• What is the overall operational concept?

• Who are the potential members of the COI in terms of the following:

• Organization, their owning agency, and reporting hierarchy

• Their data sharing needs—what information they can provide and what data they need; what data they need but currently don’t have access to

• What are the COI’s shared vocabulary concepts?

• What are the current relevant operational processes of the COI?

• What are the relevant legacy systems, interfaces, and standards?

• What are nominal scenarios for key incident types?

• What is the common information model for supporting information sharing?

• What are the COI standards for interoperability, security, and privacy in data sharing?

• What is the data quality, timeliness, and media (video, audio, telephonic, and Internet) attributes necessary for shared data?

• What are the rules (based on policy) that define data creation, update, and access authorizations based on incident type?

References

Department of Defense. 2009. Department of Defense Architecture Framework Version 2.0. http://dodcio.defense.gov/Library/DoD-Architecture-Framework.04.

Federal Enterprise Architecture Program Management Office. 2007. “FEA Consolidated Reference Model Document Version 2.3.” www.reginfo.gov/public/jsp/Utilities/FEA_CRM_v23_Final_Oct_2007_Revised.pdf.

Hong Kong International Airport. 2014. “Sustaining Our Capacity: Addressing Emerging Constraints. Sustainability Report 2013/14.” http://www.hongkongairport.com/iwov-resources/html/sustainability_report/eng/pdf/media/publication/sustainability/13_14/E_Sustainability_Report_Full.pdf, pp. 16–17.

KPMG. 2017. “Approach: The Global Strategy Group’s proprietary 9 Levers of Value approach focuses on value creation, protection, and delivery from Innovation to Results.” https://home.kpmg.com/cn/en/home/services/advisory/strategy/approach1.html.

North Atlantic Treaty Organization (NATO). 2007. “NATO Architecture Framework, v3.0.” www.nafdocs.org.

Office of Management and Budget. 2012. “The Common Approach to Federal Enterprise Architecture.” https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf.

Schaar, David, and Lance Sherry. 2017. “Analysis of Airport Stakeholders, Paper Number 109.” www.academia.edu/20996936/Analysis_of_airport_stakeholders.

SEA Network (SEA) Letter to the Stakeholder “Stakeholders Map.” http://sea2013csr.rep.message-asp.com/en/sustainability-sea/stakeholders-map#start. Retrieved on 5/1/2018.

The Open Group. 2011. “TOGAF Version 9.2.” The Netherlands: Van Haren Publishing.

United Kingdom Ministry of Defense (MOD). 2012. “Ministry of Defense Architecture Framework (MODAF).” www.gov.uk/guidance/mod-architecture-framework.

U.S. Department of Transportation. “Modernization of U.S. Airspace.” https://www.faa.gov/nextgen/.

Zachman, John A. “About the Zachman Framework.” www.zachman.com/about-the-zachman-framework.