Enterprise Architecture 

 Views and Viewpoints

DEFINITIONS

1. A View is a representation of an architecture. Architecture Views may be graphical, tabular, textual or any combination of these (as an architecuture 'product').
2. A Viewpoint is the perspective taken - for example, an End User will have a different Viewpoint than a CIO or business manager. In other words, an architecture is represented in a View that is appropriate to the audience's Viewpoint.

The value of Views and Viewpoints is that they are techniques for representing architectures to stakeholders (and inherently, the development of a design and its rationale), abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. And they provide reference artifacts for future architecture work and changes

REFERENCE VIEWS

TOGAF evolved from the US Department of Defense (DoD) Technical Architecture Framework for Information Management (TAFIM), the predecessor of DODAF. DODAF V2.0 and TOGAF both provide a practical, design agnostic method for creating enterprise architectures. The DODAF V2.0 "Fit-for-Purpose" approach for developing views, presentations, or generated reports are based on TOGAF's business, data, application, and technology views

DODAF, and the UK's Ministry Of Defence Architecture Framework (MODAF) both provide excellent reference material for Architecture Views. The Australian Department of Defence's AUSDAF also uses many Views derived from DODAF and MODAF.

TRAK, incorporating aspects of MODAF, also provides a useful Architecture Viewpoints reference - the TRAK: Enterprise Architecture Framework Viewpoints.

These Architecture Views and Viewpoints are public domain, are useful outside of the defence sector, and are freely accessible from the respective web sites:

• DODAF
• MODAF
• TRAK.

VIEWPOINT STAKEHOLDERS

Generic stakeholders within ISO/IEC 42010:

• User
• Operator
• Acquirer
• Owner
• Supplier
• Developer
• Builder
• Maintainer.

These are generic. Typically there will be cases where entirely different stakeholders need to be considered.

MAPPING DOMAINS TO VIEWS

The Viewpoints defined for AUSDAF/ DODAF/ MODAF are set out at 10 levels while the described Architecture Framework sets out 4 Domains, and the ADM sets out 3, plus the Architecture Vision. It should be noted that:

• the TOGAF ADM is generic, and is intended as guidance
• the reference Architecture Framework is a bridge to customers' frameworks and can be varied based on each customer's own EA
• the ADM and the Architecture Framework are readily inter-workable
• the Viewpoints and Views listed below provide for an added level of granularity. The use of any View or Viewpoint is purely subject to each circumstance and can be used at the Enterprise Architect's discretion.

DOMAINS MAPPED TO VIEWPOINTS

Architecture Domain Taxonomy	TOGAF ADM Architecture Domains	Viewpoints
1. Business Architecture	A. Architecture Vision	Architecture
	B. Business Architecture	Strategic Capability
		Project/Portfolio
		Operations
		Services
2. Information Architecture	C. Systems Architecture	Application
3. Systems Architecture		Systems
		Information
4. Infrastructure Architecture	D. Technology Architecture	Network
Ref. The Human View Handbook for MODAF (UK Ministry of Defence, (Draft Version 2) Second Issue - 5/10/09). The SFIA is a useful model for defining skill sets. See SFIA Foundation.		Human Factors

ARCHITECTURE DOMAINS

                               The 4 Levels of Enterprise Architecture

                                 

TAXONOMY OF ARCHITECTURE VIEWS

View Taxonomy: The organised collection of all views pertinent to an architecture.

Architecture Views may be Conceptual, Logical or Physical, each of these representing a subsequent level of detail.

Architecture Views are an aid for design. They communicate complex concepts to stakeholders, internal and external, based on those stakeholders' respective Viewpoints. Views assist in validating designs, capturing links and dependencies between architecture components (the Map views) and would be used in proposed designs and design artifacts such as certified designs. They should contribute a significant level of legitimacy to design artifacts.

Views are produced as needed. Those listed ARCHITECTURE VIEWS make up a comprehensive suite derived from the Australian, US and UK military frameworks, TOGAF and OMG. It is not usual that the full range of Architecture Views would be needed, at least initially - particularly for any one customer. Over time, however, it could be anticipated that a large artifact library would grow from the various Views constructed for various circumstances and be reference-able for future use as architecture building blocks.

Other View Taxonomies:

• TOGAF Core Taxonomy of Architecture Views (The Open Group).
• DODAF. The US Defense framework
• MODAF. The UK Ministry Of Defence framework
• OMG. The Object Modelling Group.
• Overview of DAF Products - AUSDAF

ARCHITECTURE VIEWS

The following table sets out the Views and Viewpoints adopted by the Department of Defence that also adopts those from the UK MODAF, US DODAF, TOGAF and OMG as a well developed reference. The Views are grouped as a hierarchy of Viewpoints which can be varied to suit requirements.

Viewpoint	Acronym	View	Standard	Description
Architecture	AVS	Architecture Vision	MODAF TOGAF	High level scope.Solution concept diagram illustrating the major components and how the solution results in benefits to the organisation.
	ADD	Architecture Definition	MODAF TOGAF	Deliverable container for the core architectural artifacts created during a project. The ADD spans all architecture domains (business, data, application and technology) and also examines all relevant states of the architecture (baseline, interim and target).
	AW	Architecture Waiver	AUSDAF	Provides authorisation to the project to exclude identified processes, activities and materials from their architecture
	AD	Architecture Deviation	AUSDAF	Provides authorisation to the project to deviate from identified processes, activities and materials from their architecture
	ACC	Architecture Compliance	MODAF TOGAF	A statement of architectural compliance as well as any waivers and their specifications and agreements for mitigation and future conformance.
Strategic Capability	StV-1	Strategic Vision	MODAF	The overall vision for transformational endeavours which provides a strategic context for the capabilities described and a high level scope.
	StV-2	Capability Taxonomy	MODAF	A hierarchy of capabilities which specifies all the capabilities that are referenced throughout one or more Architectural Descriptions.
	StV-3	Capability Phasing	MODAF	The planned achievement of capability at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities conditions desired effects rules complied with resource consumption and production and measures without regard to the performer and location solutions.
	StV-4	Capability Dependencies	MODAF	The dependencies between planned capabilities and the definition of logical groupings of capabilities.
	StV-5	Capability to Org Dev Map	MODAF	The fulfilment of capability requirements shows the planned capability deployment and interconnection for a particular capability phase. The CV-5 shows the planned solution for the phase in terms of performers and locations and their associated concepts.
	StV-6	Capability to OV/BP Map	MODAF	A mapping between the capabilities required and the operational activities that these capabilities support.
	StV-7	Capability to Service Map	MODAF	A mapping between the capabilities and the services that these capabilities enable.
	StV-R	Strategic Requirement Definition	AUSDAF	Strategic Requirement driving the project and mapping to the Strategic Capabilities.
Project/Portfolio	PV-1	Project Portfolio Relationship	DODAF	Describes the dependency relationships between the organisations and projects and the organisational structures needed to manage a portfolio of projects.
	PV-2	Project Timeline	DODAF	A timeline perspective on programs and projects with the key milestones and interdependencies.
	PV-3	Project to Capability Map	DODAF	A mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability.
Operations	OV-1	Operational Concept	DODAF	The high level graphical/textual description of the operational concept.
	OV-2	Operational Node Connectivity	DODAF	A description of the resource flows exchanged between operational activities.
	OV-3	Operational Info Exchange	DODAF	A description of the resources exchanged and the relevant attributes of the exchanges.
	OV-4	Command Relationship	DODAF	The organisational context role or other relationships among organisations.
	OV-5a	Operational Activity Hierarchy	DODAF	The capabilities and operational activities organised in an hierarchical structure.
	OV-5bph	Business Process Hierarchy	AUSDAF
	OV-5b	Operational Activity Model	DODAF	The context of operational capabilities and activities and their relationships among activities inputs and outputs. Additional data can show cost, performers or other pertinent information.
	OV-5bpm	Business Process Model	AUSDAF
	OV-6a	Operational Rules Model	DODAF	One of three models used to describe operational activity. It identifies business rules that constrain operations.
	OV-6b	Operational State Transition	DODAF	One of three models used to describe operational activity. It identifies business process responses to events (usually very short activities).
	OV-6c	Operational Event Trace	DODAF	One of three models used to describe operational activity. It traces actions in a scenario or sequence of events.
	OV-R	Op/Biz Requirement Definition	AUSDAF	Business Requirement driving the project and mapping to Strategic Requirements.
Services	SerV-1	Service Taxonomy	MODAF	The identification of services, service items and their interconnections.
	SerV-2	Service Resource Flows	MODAF	A description of resource flows exchanged between services.
	SerV-3a	Service-Service Map	MODAF	The relationships among or between systems and services in a given Architectural Description.
	SerV-3b	Service-Systems Map	MODAF	The relationships among services in a given Architectural Description. It can be designed to show relationships of interest (e.g. Service-type interfaces, planned vs existing interfaces).
	SerV-3c	Service-Capability Map	MODAF
	SerV-3d	Service- Operational Activity/Business Process Map	MODAF
	SerV-4	Service Functions	MODAF	The functions performed by services and the service data flows among service functions (activities).
	SerV-5	Service Orchestration	MODAF	A mapping of services (activities) back to operational activities.
	SerV-6	Service Resource Flow Matrix	MODAF	Provides details of service resource flow elements being exchanged between services and the attributes of that exchange.
	SerV-7	Service Performance Measures	MODAF	The metrics of Services Model elements for the appropriate time frames.
	SerV-8	Service Evolution Description	MODAF	The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation.
	SerV-9	Service Technology Forecast	MODAF	The emerging technologies, sw/hw products and skills that are expected to be available in a given set of time frames and that will affect future service deployment.
	SerV-10a	Service Rules Model	MODAF	One of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation.
	SerV-10b	Service State Transition Model	MODAF	One of three models used to describe service functionality. It identifies responses of services to events.
	SerV-10c	Service Event Trace Model	MODAF	One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint.
	SerV-R	Service Requirement Definition	AUSDAF	Service Requirement driving the project and mapping to Business requirements.
Application	NA	Class Diagram	OMG	Describes the structure of a system by showing the system's classes, their attributes and the relationships among the classes.
	NA	Activity Diagram	OMG	Describes the business and operational step x step workflows of components in a system. An activity diagram shows the overall flow of control.
	NA	State Diagram	OMG	Diagram describing the states and state transitions of the system.
	NA	Use Case Diagram	OMG	Describes the functionality provided by a system in terms of actors, their goals represented as use cases and any dependencies among those use cases.
	NA	Sequence Diagram	OMG	Shows how objects communicate with each other in terms of a sequence of messages. Also indicates the life spans of objects relative to those messages.
	NA	Collaboration Diagram	OMG	They represent a combination of information taken from Class, Sequence and Use Case Diagrams describing both the static structure and dynamic behaviour of a system.
	NA	Component Diagram	OMG	Describes how a software system is split up into components and shows the dependencies among those components.
	NA	Deployment	OMG	Describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
	NA	Application Requirement	AUSDAF	Application Requirements driving the project and mapping to Business and/or Service Requirements.
Systems	SV-1	Systems Interface Description	DODAF	The identification of systems, system items and their interconnections.
	SV-2	Systems Communications	DODAF	A description of resource flows exchanged between the systems.
	SV-3a	System-System Map	DODAF	The relationships among systems in a given Architectural Description. It can be designed to show relationships of interest (e.g. System-type interfaces, planned vs existing interfaces etc). SV-3.
	SV-3b	System-Service Map	DODAF	The relationship among or between systems and services in a given Architectural Description (SvcV-3a).
	SV-3c	System-Capability Map	DODAF MODAF	Matrix/mapping
	SV-3d	System-Operational Activity/Business Process Map	DODAF MODAF	Matrix/mapping
	SV-4	System Functions	DODAF	The functions (activities) performed by systems and the system data flows among system functions (activities).
	SV-5	SoS reserved	DODAF
	SV-6	System Data Exchange Map	DODAF	Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange.
	SV-7	System Performance Parameters	DODAF	The metrics of System Model elements for the appropriate timeframe(s).
	SV-8	System Evolution Description	DODAF	The planned incremental steps toward migrating a suite of systems to a more efficient suite or toward evolving current systems to a future implementation.
	SV-9	System Technology Forecast	DODAF	The emerging technologies, sw/hw products and skills that are expected to be available in a given set of time frames and that will affect future system deployment.
	SV-10a	System Rules Model	DODAF	One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.
	SV-10b	System State Transition Model	DODAF
	SV-10c	Systems Event-Trace Model	DODAF
	SV-R	System Requirements Definition	AUSDAF	System Requirements driving the project and mapping to Strategic, Business and/or Systems Requirements.
Information	IV-1	Conceptual Data Model	DODAF	High Level Conceptual Data Model. ERD or Class Diagram. Identifies MDM Subject Areas inclusive of Conceptual Entities. Relationships do not indicate cardinality or optionality.
	IV-2	Logical Data Model	DODAF	Logical Data Model. ERD or Class diagram. Extends selected MDM Subject Areas and Conceptual Entities for use within segments, programs, projects. Includes Entities and attributes information. Relationships should indicate cardinality or optionality.
	IV-3	Physical Data Model	DODAF	Physical Data Model. Erd or Class Diagram. Extends selected LDM into physical schemas for use within segment, program or project architectures. Transforms Entities to Tables and Attributes to Properties inclusive of data typing and sizing. Relationships must indicate cardinality or optionality. DBMS platform can be specified for DDL production.
	IV-4	Physical Exchange Specification	AUSDAF	Physical Exchange Specification in either DDL or XML (XSD) or other definition language to support relational DB, object-relational DB, BI-cfube or SOA WDSL or use of the data structure.
	IV-5a	Conceptual Data to Capability Map	DODAF	matrix/mapping
	IV-5b	Logical Data to Operational Activity/Business Process Map	DODAF	matrix/mapping
	IV-5c	Physical Data to Service Map	DODAF	matrix/mapping
	IV-5d	Physical Data to System Map	DODAF	matrix/mapping
	IV-5e	Information to Network Map	DODAF	matrix/mapping
	IV-R	Information Requirements Definition	AUSDAF	Information requirements driving the project and mapping to Strategic, Ops/Business, Service, Application, System or Network Requirements.
Network	NetV-1	Conceptual Network Model	AUSDAF	High Level Conceptual Network Model (Conceptual Topology). Composite illustration of the users, services, systems that exist in the networked environment. Notion of geography is not necessary. Focus on the network as communication vehicle of the various types of networked users or nodes.
	NetV-2	Logical Network Model	AUSDAF	Logical network Model (Logical Topology). Composite illustration of a network, services (consumers/providers), systems/platforms that exist in the networked environment. Notion of geography is not necessary. Focus on the network as communication vehicle for the various types of networked users or nodes.
	NetV-3	Physical Network Model	AUSDAF	Physical network Model (Physical Topology). Composite illustration of physical components of the network infrastructure, inclusive of transmission protocols and standards, security accreditation limitations, ports, mac and IP addresses etc.
				Network nodes can be illustrated but may become overwhelming if documentation of all nodes is desired. If so, the PN model should be decomposed into network segments or sub-nets. Notion of geography, distance and other physical environmental parameters is desirable. Focus on the network as an infrastructure pattern is desirable.
	NetV-4	Network Deployment Model	AUSDAF	Net Deployment model is a Physical Network Model (Physical Topology) however focuses a specific instance rather than an architectural pattern, much like the PES in the information space. Composite illustration of physical components of the network infrastructure, inclusive of transmission protocols and standards, security accreditation limits, equipment, ports, MAC and IP addresses etc. Network nodes can be illustrated but may become overwhelming if documentation of all nodes is desirable. If so, the PN model should be decomposed into network segments or sub-nets. Notion of geography, distance and other physical environmental parameters is required. Focus on the network as an infrastructure pattern is desired.
	NetV-5a	Conceptual Network to Capability Map	AUSDAF	matrix/mapping
	NetV-5b	Logical Network to Operational Activity/Business Process Map	AUSDAF	matrix/mapping
	NetV-5c	Logical Network to Service Map	AUSDAF	matrix/mapping
	NetV-5d	Physical Network to System Map	AUSDAF	matrix/mapping
	NetV-5e	Network to Information Map	AUSDAF	matrix/mapping
	NetV-R	Network Requirements Definition	AUSDAF	Network Requirements driving the project and mapping to Strategic, Ops/Business, Service, Application, System or Information Requirements.
Human Factors	HV-A	Personnel Availability	MODAF	Defines the requirements and processes to ensure that personnel with the right characteristics and in the right numbers are available for posts/jobs.
	HV-B	Quality and Objectives Map	MODAF	Provides a repository for human-related performance criteria, including qualitative values and quantifiable metrics with measurable targets.
	HV-C	Human Interaction Structure	MODAF	Captures the structure of human networks supported by the technology, including the operational dependencies and constraints underlying information handling.
	HV-D	Organisation by Role	MODAF	Defines organisational properties and relationships including fixed and task organised structural dependencies besides organisational policies values and procedures.
	HV-E	Human Functions and Tasks	MODAF	Specified human functions and activities in relation to systems definitions as part of detailing solutions beyond OV-5 requirements.
	HV-F	Roles and Competencies	MODAF	Specifies requirements for human resources by linking human tasks, competencies and roles.
	HV-G	Dynamic Drivers of Behaviour	MODAF	Captures the factors that affect, constrain and characterise human behaviour to create a bridge between static architectural definitions and behaviour predictions.