All Views (AV)
AV-1 Overview & Summary Information
The overview and summary information contained within the AV-1 product provides executive-level summary information in a consistent form that allows quick reference and comparison between architectural descriptions.
AV-1 includes assumptions, constraints, and limitations that may affect high-level decisions relating to an architecture-based work programme.
In an enterprise repository environment, individual architectures are mapped against enterprise phases to provide context between the architectures.
Background:
The architecture development must be framed in the context of the AV-1 product.
AV-1 contains sufficient textual information to enable a reader to select one Architecture from among many to read in more detail.
AV-1 serves two additional purposes:
- In the initial phases of architecture development it serves as a planning guide.
- When the architecture is built, this product provides summary information concerning “who, what, when, why, and how” of the plan as well as a navigation aid to the views that have been created.
Usage:
- Scoping the project
- Providing context to the project
- Definition of an architecture-based task
- Summarising the findings from an architecture-based task
- Assisting search within an architecture repository
Data objects:
The data in an AV-1 can include:
- Scope, purpose
- Listing of views used
Relationships Between Key Data Objects (Simplified from M3)
Representation:
- Structured Text
Detailed Product Description:
AV-1 provides an overview for an architecture description. The Overview and Summary Information provides executive-level summary information in a consistent form that allows quick reference and comparison between Architectures. AV-1 includes assumptions, constraints, and limitations that may affect high- level decisions relating to the Architecture.
AV-1 is usually a structured text product. An architecting organisation may create a template for the AV-1 that can then be used to create a consistent set of information across different architecture-based projects.
AV-1 provides a summary of a given Architecture and it documents the following descriptions:
- Architecture Project Identification – Identifies the Architecture project name, the architect, and the organisation developing the Architecture. It also includes assumptions and constraints, identifies the approving authority and the completion date, and records the level of effort required to develop the Architecture.
- Scope – Identifies the Views and Products that have been developed and the temporal nature of the Architecture, such as the time frame covered, whether by specific years or by designations such as current, target, transitional, and so forth. Scope also identifies the Enterprises and Enterprise Phases that fall within the scope of the Architecture.
- Purpose and perspective – Explains the need for the Architecture, what it will demonstrate, the types of analyses that will be applied to it, who is expected to perform the analyses, what decisions are expected to be made on the basis of each form of analysis, who is expected to make those decisions, and what actions are expected to result. The perspective from which the Architecture is developed is identified.
- Context – Describes the setting in which an Architecture exists. Context includes such things as: mission, doctrine, relevant goals and vision statements, concepts of operation, scenarios, information assurance context (e.g. types of system data to be protected, such as classified or sensitive but unclassified, and expected information threat environment), other threats and environmental conditions, and geographical areas addressed, where applicable. Context also identifies authoritative sources for the standards, rules, criteria, and conventions that are used in the architecture. Any linkages to parallel architecture efforts should be identified.
- Status – Describes the status of the architecture at the time of publication or development of the AV-1 (which might precede the architectural development itself). Status refers to creation, validation and assurance activities.
- Tools and File Formats Used – Identifies the tool suite used to develop the Architecture and file names and formats for the Architectural Products if appropriate.
- Assumptions and Constraints.
- Date completed.
An illustrative example is provided below.
Example AV-1 (Source: DCSA)
If the architecture is used to support an analysis, the AV-1 may be extended to include:
- Findings – States the findings and recommendations that have been developed based on the architectural effort. Examples of findings include: identification of shortfalls, recommended system implementations, and opportunities for technology insertion.
- Costs – the costs that have been incurred in developing the architecture and/or undertaking the analysis. This might include integration costs, equipment costs and other costs.
This is illustrated below.
Example AV-1 (Source: US DoD)
During the course of developing an Architecture, several versions of the AV-1 may be produced. An initial version may focus the effort and document its scope, the organisations involved, and so forth. After other View Products within an Architecture’s scope have been developed and verified, another version may be produced to document adjustments to the scope and to other aspects of the Architecture that may have been identified.
After an Architecture has been used for its intended purpose, and the appropriate analysis has been completed, a final version should be produced to summarise these findings for high level Decision makers. In this version, the AV-1 Product and a corresponding graphic in the form of an OV-1 Product serve as an executive summary of the Architecture.
The AV-1 can be particularly useful as a means of communicating the methods that have been applied to create View Products and the rationale for grouping these View Products. Modelling assumptions that have shaped individual View Products may also be included. In this form the AV-1 will list each individual View Product and provide a brief commentary.
Regarding ‘perspective’, this could take several forms:
- it could refer to one or more MODAF viewpoints
- it could refer to the MODAF Community of Interest
- it could refer to a focus for the work, e.g. integration or security
- or it could refer to a combination of these.
Regarding modelling constructs, this baseline of MODAF has reflected some changes in terminology relating to a desire for a degree of alignment with the IEEE-1471 standard. Complete alignment is not possible because IEEE-1471 is a standard for technical architectures and this does not directly translate to enterprise architecture.
An enterprise has an architecture, which is manifested through an architectural description (in this case, a MODAF-compliant one). That architectural description consists of a number of view products each of which is an instance of a specific view. In a sense the view provides a template for the products. (Note that there may be several products conforming to any particular view template.)
The framework consists of a set of views (view templates) and these are organised in terms of viewpoints. This terminology differs considerably from that used in IEEE-1471 which also uses the terms ‘view’ and ‘viewpoint’. Where MODAF and IEEE-1471 agree is that a key ingredient of the framework is describing the allowable set of methods or modelling techniques that support any given view. A concrete example of this is MODAF view OV-5 for activity modelling. The activity modelling methods currently allowed are UML and IDEF0. Consideration in future will be given to SysML and BPMN.
Also MODAF agrees with IEEE-1471 in that each view is associated with a specific set of concerns that certain stakeholders have, and which the view products constructed from the view templates are intended to address. Taking OV-5 as an example here, this is the unique view in the framework that is intended to address the concerns relating to business process.
The stakeholder groupings tend to align with the Viewpoint definitions (so the MODAF Operational Viewpoint relates to operational stakeholders, i.e. end users).
Finally each Architectural Description has a rationale, that governs the selection of views that will be used and the scope of the underlying models. The AV-1 view is intended to describe this.
Page version 1.1, dated 4th April 2007