This viewpoint is called the All Viewpoint for good reason—it provides all the information you need to understand and interpret all the other viewpoints included in an architecture. The All Viewpoint provides an executive summary of the architecture and development effort and detailed definitions and explanations of all the terms used in the architecture. The All Viewpoint provides essential support to the repository that must hold all the architecture data from all the viewpoints and to the architecture development team that has to develop an integrated architecture and must coordinate and integrate many viewpoints and views.

The All Viewpoint is where we state the scope of an architecture effort in terms of coverage, the types of questions it is supposed to answer, and the key stakeholders involved in terms of the sponsors of the architecture effort. These sponsors and stakeholders participate in the architecture development and ultimately in its deployment as a solution or a collection of solutions to business problems.

The All Viewpoint content corresponds to information developed in the TOGAF Architecture Vision phase of the Architecture Development Methodology (ADM) that includes views such as the solution concept diagram, the stakeholder map matrix, and the value chain diagram. (See Chapter 22.)

The All Viewpoint content also corresponds to information developed in step 1 of the Collaborative Planning Methodology in the FEAF2. In step 1, the scope and purpose of the architecture is defined and the stakeholders and their needs are identified. This step is responsible for identifying the major drivers for change and defining, validating, and prioritizing the operational realities of the mission and goals with leadership, stakeholders, and operational staff. (See Chapter 23.)

Introduction to the Views in the All Viewpoint

The All Viewpoint contains two views: AV-1: Overview and Summary Information and AV-2: Integrated Dictionary. These views are introduced in this section. Details of the All Viewpoint views and examples are provided in subsequent sections.

AV-1: Overview and Summary Information

The Overview and Summary Information view (see Figure 12-1) is a living document that contains a current overview of the architecture form and contents. As such, it contains much of the information developed in the first four steps of the Six-Step Process, such as the architecture purpose, the scope of the architecture, and the views contained in the architecture (see Chapter 5). The AV-1 describes the assumptions and constraints that bound the architecture effort. The AV-1 is usually started as the first view of the architecture development, and it should be updated as the development proceeds and iteration through the Six-Step Process results in changes to the views being developed or changes to their details. As releases of the architecture occur, the AV-1 should be updated with the findings and recommendations associated with the release. The AV-1 usually also has a high-level schedule outlining the planned release dates for the architecture.

Figure 12-1   Integrated model for AV-1: Overview and Summary Information

The AV-1 acts simultaneously as an advertising document, an informative abstract, and an executive summary for the architecture. It also describes the types of planned analysis during development or after the architecture is developed, and at the end of each release of the architecture effort, it is used for recording analysis results, findings, and recommendations for future actions. The AV-1 is also frequently expanded to provide the development plan for the architecture, including such information as configuration management, versioning, and release.

AV-2: Integrated Dictionary

The Integrated Dictionary view is an authoritative and integrated dictionary for all architecture elements or terms used in all views that support all viewpoints (see Figure 12-2). The AV-2 is not a simple glossary nor is it restricted to a single view, although extracts from the AV-2 may be presented with each view in hard-copy documents to make reading easier. The integrated dictionary forces disparate elements from multiple views to be resolved by the modeling teams and presents consistent and distinct architecture elements. The AV-2 may also contain taxonomies (classification schemes) for architecture elements to provide abstraction hierarchies that enable integration of detailed views with abstract views. The AV-2 may also contain semantic relationships. The AV-2 is the place for the architect to document any additional information he or she believes is important for understanding the architecture elements.

Figure 12-2   Integrated model for AV-2: Integrated Dictionary

The AV-2: Integrated Dictionary view is usually generated in a tabular format with a long list of architecture elements, their acronyms expanded, their descriptions, authoritative sources that are the origins of the definitions, and a cross-reference of usage of architecture elements in the various views of the architecture description. Many architecture tools automatically generate the AV-2 as a byproduct of architecture development but the ultimate burden of ensuring an integrated architecture, that is, the consistent use of architecture elements across views, still falls on the architect. This is also true for architecture repositories that generate the AV-2 automatically for a specific architecture. The AV-2 is one of the most labor-intensive views in the architecture, even with automated support. This means that entries should be developed or updated as the other views are developed, with conflicts resolved as quickly as possible.

The AV-2 is a valuable tool for the architecture integrator—the person or persons responsible for delivering an integrated architecture. When the same architecture element is named differently in different views, integration does not occur. Analysis will be faulty, as the intersection of common elements across views will not occur and any searching and querying method returns incomplete information. It is recommended that the AV-2 be continuously generated throughout the architecture development and efforts expended to ensure that the architecture elements are constantly reviewed for consistency, especially if multiple people are developing different views at different locations and bringing them together for integration.

Alternative Views

In TOGAF 9.2, additional views are recommended to support the Preliminary phase and the Architecture Vision phase of the Architecture Development Methodology (ADM), where the All Viewpoint views are developed. The additional views are listed here:

• Architecture Vision   Created early on in the project life cycle and provides a high-level, aspirational view of the end architecture product. The purpose of the vision is to agree at the outset what the desired outcome should be for the architecture, so that architects can then focus on the critical areas to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing an executive summary version of the full architecture definition.

• Principles Catalog   Lists the guiding principles for architecture development.

• Stakeholder Map Matrix   Depicts the stakeholders and their roles in the architecture.

In the TOGAF, the architecture repository plays the part of and stores the Integrated Dictionary (AV-2). In addition, the architecture requirements specification is an important document that acts as a companion to the Overview and Summary Information (AV-1). The architecture roadmap lists individual increments of change and lays them out on a timeline to show progression from the baseline architecture to the target architecture. The architecture roadmap forms a key component of transition architectures and is incrementally developed throughout phases B, C, D, E, and F within the ADM.

Another important view that supports the All Viewpoint is the request for architecture work (TOGAF) or a statement of work (federal) that describes the tasks that are to be performed during the architecture development. “The Statement of Architecture Work defines the scope and approach that will be used to complete the architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services” (TOGAF Version 9.2, p 363).

AV-1: Overview and Summary Information

The AV-1 can be short and provide the minimum metadata related to an architecture development. It can also be a long and comprehensive description of the context of the architecture with a detailed description of the problem that is being addressed by and the details of the architecture development. Many enterprises standardize the format of the AV-1 to enable uniform registration of multiple architectures using similar attributes. An integrated architecture repository that is used to automatically generate the text-based AV-1 will also enforce this discipline.

Table 12-1 shows an example short-form template for the AV-1.

Table 12-1   AV-1 Sample Architecture Overview and Summary Template

When views are identified in the AV-1, the information on the view should not just identify the name of the view (in terms of the selected framework) but also the specific format or formal modeling technique being used. If an unusual modeling technique or format is used, a reference to a description of the technique or format should be included. The intent of this element of the AV-1 is to let the reader understand what to expect in terms of the architecture contents and what background or expertise may be necessary to read, understand, and interpret the views.

Example: Richard M Nixon Airport Enterprise Architecture (RMN-EA) Overview and Summary Information

The following example shows an AV-1 for the RMN Airport Enterprise Level architecture. This AV-1 is intended to be a foundational document for a multiyear enterprise transformation. The primary purpose of the AV-1 is to establish a lasting and living directional document for EA development and for communications with executive and business management as well as other stakeholders. General background for the RMN Airport Case Study can be found in Chapter 3.

Architectural Description Identification

Name of architecture:   Richard M. Nixon International Airport Enterprise Level Architecture (RMN-ELA)

Name of the architect:   Chief Architect, RMN Airport

Name of the organization developing the architectural description:   RMN Airport Enterprise Architecture Department

List of assumptions and constraints:

• Assumptions   RMN must comply with regulations from the following organizations: Federal Aviation Administration for Flight Safety and Air Traffic Management; Department of Homeland Security and Transportation Safety Administration for Passenger, Baggage, and Cargo–related constraints as well as requirements for airport terminal safety; state, county, and city regulations for local ordinances related to noise pollution, traffic, and other items; Environmental Protection Agency for hazardous cargo, pollution, disposals; OSHA for occupational safety and health of airport staff and contract personnel; Sarbanes-Oxley for fiscal and operational transparency of RMN operations.

• Constraints   For the first version of the EA, only limited access to stakeholders and subject matter experts is available because of unavailable time or access and insufficient resources to canvass and arrange interviews and set up post-processing of interview results. RMN is an ongoing operation where execution of activities takes precedence to EA and planning-related activities that are perceived as peripheral and potentially counterproductive. Until the EA can produce results that command attention, this will remain a culture issue. For the first version of the EA, the culture of treating EA and planner interactions as a low priority item compared to addressing the operational challenges of the day will remain a barrier.

Approval authority:   RMN Airport Authority

Architecture completion date:   1/1/2018

Description of the level of effort required:   6 staff months

Scope

Viewpoints addressed by the architecture description: Capability Viewpoint, Project Viewpoint, Operational Viewpoint

Views developed:

• CV-1: Vision   Multiphase version with strategic vision, phases, capabilities, and goals; objectives and measures documented in the AV-1

• CV-2: Capability Taxonomy   Hierarchical list

• CV-3: Capability Phasing   Graphic showing capability versus capability configurations (using system-related project names) on a three-year timeline

• CV-4: Capability Dependencies   Graphic showing capability dependencies with dependent capabilities at the arrow tail and capabilities they depend on at the head of arrows

• CV-5: Capability to Organizational Development Mapping   Graphic showing organizations versus capabilities with capability configurations and interfaces between them for the mid- to late-phase 1 time frame

• PV-1: Project Portfolio Relationships   Table of projects, description, and start and stop dates organized by owning organizations

• PV-2: Project Timelines   Graphic showing one timeline per project with relevant delivery milestones and showing dependencies of each project on deliveries from other projects

• PV-3: Project to Capability Mapping   Matrix of projects versus capabilities showing which projects contribute to which capabilities

• OV-4: Organizational Relationships Chart   RMN organizational chart showing internal RMN organizations plus enterprise context organizational chart showing all the organizations involved in operating the airport

Time frame addressed:   15-year, three-phase, RMN transformation period

Organizational entities in scope:   All the organizations involved in operating the airport including the RMN Airport internal organizations

Purpose and Perspective

The need:   Provide a roadmap for transforming RMN Airport from a general aviation field into an international airport providing an alternative (reliever airport) to LAX and other Los Angeles area airports

The types of analyses:   Financial analyses on funding sources (bonds and operational revenue) versus expected costs of capability development

Who is expected to perform the analyses:   RMN Airport Finance Division with assistance from contractors as necessary

What decisions are expected to be made based on each form of analysis:   Prioritization of capability development

Who is expected to make those decisions:   RMN Airport Authority

What actions are expected to result:   Updates/changes to RMN Airport capability portfolios both in terms of content and timing; updates to RMN-ELA

The perspective from which the architectural description is developed:   The perspective used is that of RMN executive management.

Context

Mission addressed by the architecture:   RMN transformation

Doctrine:   N/A, although some FAA regulations and requirements may approach doctrine

Relevant goals and vision statements:   Vision (from RMN Airport Master Plan) – Upgrade RMN Airport to become a viable alternative to LAX for passengers as an en route point or a destination all within a 15-year time frame

Concepts of operation:   Implied by FAA, TSA, CBP, ICE, and law enforcement standards and procedures

Scenarios:   N/A

Information assurance context:   Security requirements specified by FAA, NIST, federal, and law enforcement standards as well as state and local regulations on privacy

Other threats and environmental conditions:   TBD

Geographical areas addressed:   RMN Airport grounds, airspace, and business offices

Authoritative sources:   As noted previously for security requirements; FAA standards for airport planning, runways, airport equipment and instrumentation, air traffic personnel, airline staff, and air crew; state and local regulations for zoning, noise, and traffic; relevant regulations from involved federal agencies (such as TSA, CBP, and ICE) and law enforcement; OSHA regulations

Any linkages to related architecture efforts:   RMN Airport will also be developing a Segment Level architecture for passenger management and a Solution Level architecture for passenger identification.

Status

Current Status:   Draft RMN-ELA version 0.5 completed

Tools and File Formats

Tool suite used:   MS Office products

Filenames and formats:   N/A - hard copy

Architecture Development Schedule

Start date:   6/1/2017

Development milestones:   Draft version 0.5 complete 1/1/2018

Date completed:   TBD

Findings

Findings and recommendations:   TBS (to be supplied)

Costs

Architecture budget:   12 staff months

Cost projections:   12 staff months

AV-2: Integrated Dictionary

Before the DoDAF was developed, architecture projects delivered several models, each of which was accompanied by its own glossary. Each glossary defined the architecture elements specific to a single model. The DoDAF is designed to produce an integrated architecture where the architecture elements of the same name have the same definition regardless of the view in which it appears. Similarly, any two elements with the same definition should have the same name. The AV-2 is a mechanism to get architects to resolve name conflicts and definitional issues across views and provides a single, consistent dictionary for the architecture as a whole.

Example: Integrated Dictionary Sample Entries

The following example provides sample entries for different types of architecture elements taken from RMN Airport architectures (Enterprise, Segment, or Solution Level). AV-2 entries can be tailored by adding more information as well as alternative terms for the same architecture element (synonyms). Additional dictionary entries are provided in Chapters 13–19 for elements in various views.

Summary

The All Viewpoint has two views and is used by all stakeholders and readers of the architecture. The AV-1: Overview and Summary Information provides an executive level summary of the purpose and contents of the architecture as well as providing conclusions and recommendations based on the current release of the architecture. More than just a glossary, the AV-2: Integrated Dictionary provides a consistent set of definitions and other information for all of the architecture elements and terms used in the architecture. The AV-2 provides the basis for ensuring the architecture is integrated and provides a place to document information about architecture elements that may be needed to fully interpret the architecture.

Questions

1. For which types of stakeholders does the All Viewpoint provide benefits?

2. What are the challenges you foresee in developing an AV-1 for your own project in the following areas:

• Identifying and stating the problem that needs to be solved by using the architecture development as a representational and clarifying exercise?

• Identifying the stakeholders who are involved and must sponsor, collaborate, support, and be the audience for the architecture development?

• Identifying the types of questions the architecture must answer as well as the types of analysis that must be performed? The data that is needed by the analyses?

• Identifying, specifying, and restricting yourself to a stated scope to prevent project or program creep?

3. True or False? Provide clarifying statements to support your answer.

A. The AV-1 is the very first model (or artifact) that is built in order to establish the scope, purpose, viewpoints, and models that will be covered by the architecture effort.

B. The AV-1 is the very last model to be completed, because at the end of an architecture development, the architecture team records its findings and recommendations inside the AV-1.

4. What is the advantage of an integrated architecture dictionary (a single one for an entire architecture development effort) versus having a separate model glossary for each model that is built? What are the pros and cons?

5. What are the dimensions of scope that are described inside an AV-1? (Hint: breadth of architecture modeling domain and numbers and types of models built and many others.)

6. For your own enterprise, who would be the various stakeholders in the enterprise architecture? What are the types of models you would build to provide value to them?

7. What is the purpose of including architecture development time frames, costs, levels of effort involved, and development organizations inside the AV-1?

8. What are the pros and cons of using the AV-1 as an “index card” to contain information about your architecture in some larger architecture library or registry? The Defense Architecture Registry System (DARS) is one such registry. What would you recommend as a method or mechanism to transmit, store, and manage the AV-1 in such a registry? How would someone use “discovery” techniques to browse such a registry?

9. What are the types of architecture elements documented in the AV-2: Integrated Dictionary?

10. What is the purpose of the Integrated Dictionary?

11. What are some of the challenges in integrating AV-2 dictionaries across different enterprises? Discuss some of the problems with structural integration such as data formats as well as semantic integration—differences in vocabularies and meanings.

References

Department of Defense. 2009. DoD Architecture Framework Version 2.0. “Volume 1: Introduction, Overview, and Concepts.” http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF%20V2%20-%20Volume%201.pdf.

Department of Defense. 2009. DoD Architecture Framework Version 2.0. “Volume 2: Architectural Data and Models.” http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF%20V2%20-%20Volume%202.pdf.

Department of Defense. “DoDAF Viewpoints and Models: All Viewpoint.” http://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_all_view/.

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