第1页 / 共289页
第2页 / 共289页
第3页 / 共289页
第4页 / 共289页
第5页 / 共289页
第6页 / 共289页
第7页 / 共289页
第8页 / 共289页
最新版dodaf 2-02.pdf
defense.gov
DoDAF Architecture Framework Version 2.02
DoDAF Journal
DoDAF Architecture Framework Version 2.0 Links
Microsoft Word - DM2 VDD v2.02.doc
DoDAF Contacts
DoDAF Introduction
DoDAF Architecture Development - 6 Step Process
DoDAF Introduction
DM2 - DoDAF Meta-Model
DoDAF Viewpoints and Models
Architecture Presentation Techniques
CM Overview
Glossary
DoDAF Architecture Framework Version 2.0 Sitemap
DoDAF Architecture Framework Version 2.0 Archives
Enterprise Architecture based on Design Primitives
Enterprise Architecture based on Design Primitives
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Section_9-3-9_Quality_Planning.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_7-2-1_Component_Models.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_7-2-2_Deployment-Operational_Models.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_7-1-3_Arch_Maturity_PDCA_Cycle.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_5-4-4_GAO_and_OMB_Arch_Assessment.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_5-4-4_Compliance_Review.pdf
http://cio-nii.defense.gov/sites/dodaf20/products/Vol_1_Sect_6-1_Arch_Support_in_Decision_Making.pdf
DoDAF Plenary Presentations 12 AUG 10
DoD EA Conference 2010 Presentations
DoDAF Journal FAQs
DoDAF Journal Archives
DoDAF Journal Contacts
Architecture Development - Architect
DoDAF Meta-Model Logical Model
Architecture Development - Security
Models - Model List
Models - Mapping to DM2
DM2 - The DoDAF Conceptual Data Model
Physical Exchange Specification
DoDAF Formal Ontology
DoDAF Viewpoints and Models - All Viewpoint
DoDAF Viewpoints and Models - Capability Viewpoint
DoDAF Viewpoints and Models - Data and Information Viewpoint
DoDAF Viewpoints and Models - Operational Viewpoint
DoDAF Viewpoints and Models - Project Viewpoint
DoDAF Viewpoints and Models - Services Viewpoint
DoDAF Viewpoints and Models - Standards Viewpoint
DoDAF Viewpoints and Models - Systems Viewpoint
Architecture Development Composite Views
Architecture Development Fusion Views
Architecture Development Reference Models
Architecture Development - Architecture Planning
Microsoft PowerPoint - UPDMUpdate4DoDArchitecturePlenary(12Aug2010)
DoD Architecture: Standards-based Model and Data Interchange at the Object Management Group (OMG)
Enterprise Architecture based on Design Primitives
Enterprise Architecture based on Design Primitives
Microsoft Word - Essential DoDAF 2009-05-20.doc
Using Architectural Metadata
What is New in DoDAF V2.0
DoDAF 2.0 Vision
DoDAF Architecture Resources
DoDAF V1.5 Support
Relationships to other Frameworks
Architecture Development Methodologies
DoDAF Architecture Development - 6 Step Process
DoDAF Architecture Development - Decision Maker
Architecture Development - Enterprise Architecture
Architecture Development - Scoping Architectures
Architecture Development - Analytics
DoDAF Manager Role
DoDAF Architect Role
DoDAF Developer Role
DoDAF Meta-Model Logical Model
Model
DoDAF Meta-Model Logical Model
DoDAF Meta-Model Logical Model
DM2 - Performers
DM2 - Resource Flows
DM2 - Information and Data
DM2 - Rules
DM2 - Goals
DM2 - Capability
DM2 - Services
DM2 - Project
DM2 - Reification
DM2 - Organizational Structure
DM2 - Measures
DM2 - Locations
DM2 - Pedigree
All Viewpoints - Overview
All Viewpoints - Integrated Dictionary
DoDAF - Viewpoints CV-1: Vision
DoDAF - Viewpoints CV-2: Capability Taxonomy
CV-3: Capability Phasing
DoDAF - Viewpoints CV-4: Capability Dependencies
CV-5: Capability to Organizational Development Mapping
Models - Model Categories
Models - Levels of Architecture
Models - Architecture Interrogatives
Models - Architecture Modeling Primitives
CV-6: Capability to Operational Activities Mapping
CV-7: Capability to Services Mapping
DIV-1: Conceptual Data Model
DIV-2: Logical Data Model
DIV-3: Physical Data Model
OV-1: High Level Operational Concept Graphic
OV-2: Operational Resource Flow Description
OV-3: Operational Resource Flow Matrix
OV-4: Organizational Relationships Chart
OV-5a: Operational Activity Decomposition Tree and OV-5b: Operational Activity Model
OV-6a: Operational Rules Model
OV-6b: State Transition Description
OV-6c: Event-Trace Description
PV-1: Project Portfolio Relationships
PV-2: Project Timelines
PV-3: Project to Capability Mapping
SvcV-1: Services Interface Description
SvcV-2: Services Resource Flow Description
SvcV-3a: Systems-Services Matrix
SvcV-3b: Services-Services Matrix
SvcV-4: Services Functionality Description
SvcV-5: Operational Activity to Services Traceability Matrix
SvcV-6: Services Resource Flow Matrix
SvcV-7: Services Measures Matrix
SvcV-8: Services Evolution Description
SvcV-9: Services Technology and Skills Forecast
SvcV-10a Services Rules Model
SvcV-10b Services State Transition Description
SvcV-10c Services Event-Trace Description
StdV-1: Standards Profile
StdV-2: Standards Forecast
SV-1: Systems Interface Description
SV-2: Systems Resource Flow Description
SV-3: Systems-Systems Matrix
SV-4: Systems Functionality Description
SV-5a: Operational Activity to Systems Function Traceability Matrix
SV-5b: Operational Activity to Systems Traceability Matrix
SV-6: Systems Resource Flow Matrix
SV-7: Systems Measures Matrix
SV-8: Systems Evolution Description
SV-9: Systems Technology and Skills Forecast
SV-10a: Systems Rules Model
SV-10b: Systems State Transition Description
SV-10c: Systems Event-Trace Description
DM2 - The DoDAF Conceptual Data Model
DM2 - The DoDAF Conceptual Data Model
DM2 - The DoDAF Conceptual Data Model
Model
Model
Model
Model
OSD Org Server Questionnaire Analysis Report
http://cio-nii.defense.gov/sites/dodaf20/images/financial_data_fusion_view.gif
Architecture Development - Detailed Planning
Approaches to Architecture Development
DoDAF Architecture Framework Version 2.02
Department of Defense
Home
DoDAF-DM2 WG
DoDAF Journal
DoD Meta Data Registry
IDEAS
Links
Background
Architecture Development
Meta Model
Viewpoints & Models
Presentation Techniques
Configuration Management
Overview
Acronyms List and Glossary
of Terms
Site Map
Archives
The DoDAF Architecture Framework Version 2.02
Welcome to DoDAF Version 2.02! This is the official and current version for the Department
of Defense Architecture Framework.
Version 2.02
This is the current release of DoDAF as of August
2010.
A PDF version of this website is produced
periodically and can be downloaded here: DoDAF
2.02.pdf
For a description of changes made to DoDAF/DM2
2.01 to create DoDAF/DM2 2.02, download the Version Description Document here.
DoDAF Conformance
DoD Components are expected to conform to DoDAF to the maximum extent possible
in development of architectures within the Department. Conformance ensures that
reuse of information, architecture artifacts, models, and viewpoints can be shared with
common understanding. Conformance is expected in both the classified and
unclassified communities, and further guidance will be forthcoming on specific
processes and procedures for the classified architecture development efforts in the
Department.
DoDAF conformance is achieved when:
The data in a described architecture is defined according to the DM2 concepts,
associations, and attributes.
The architectural data is capable of transfer in accordance with the PES.
DoDAF Journal
The DoDAF Journal is a community of interest based discussion board. The Journal includes
descriptions of best practices, lessons learned, example views and DM2 datasets, DoDAF
model templates, DoDAF meeting presentations, and tutorial materials, and reference
documents. It can be used by reference, component, capability, segment, and solution
architects and core process stakeholders. Any member of the DoDAF community may submit
material for publication and an editorial board will work with the authors to determine
appropriateness, ensure public releasability, and make any needed changes to content.
Contact Information
For any general enquiries, please contact us via the general enquiry mailboxes listed on our
contact page.
http://cio-nii.defense.gov/sites/dodaf20/index.html[3/3/2011 3:33:35 PM]
1
DoDAF Architecture Framework Version 2.02
Go to top of page ↑
Privacy Policy | Web Policy | Contacts
http://cio-nii.defense.gov/sites/dodaf20/index.html[3/3/2011 3:33:35 PM]
2
DoDAF Introduction
Department of Defense
Home
DoDAF-DM2 WG
DoDAF Journal
DoD Meta Data Registry
IDEAS
Links
Background
Six Core Processes DoDAF
Supports
DM2 Support for the Six Core
Processes DoDAF Supports
What is New in DoDAF V2.0
Architecture Development
Meta Model
Viewpoints & Models
Presentation Techniques
Configuration Management
Overview
Acronyms List and Glossary
of Terms
Site Map
Archives
Introduction
The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the
overarching, comprehensive framework and conceptual model enabling the development of
architectures to facilitate the ability of Department of Defense (DoD) managers at all levels
to make key decisions more effectively through organized information sharing across the
Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.
The DoDAF serves as one of the principal pillars supporting the DoD Chief Information
Officer (CIO) in his responsibilities for development and maintenance of architectures
required under the Clinger-Cohen Act. DoDAF is prescribed for the use and development of
Architectural Descriptions in the Department. It also provides extensive guidance on the
development of architectures supporting the adoption and execution of Net-centric services
within the Department.
DoD managers, as process owners, specify the requirements and control the development of
architectures within their areas of authority and responsibility. They select an architect and
an architecture development team to create the architecture in accordance with the
requirements they define.
DoD Components are expected to conform to the DoDAF developing architectures within the
Department. DoDAF Conformance ensures reuse of information and that architecture
artifacts, models, and viewpoints can be shared with common understanding.
DoDAF V2.0 focuses on architectural "data", rather than on developing individual "products"
as described in previous versions. In general, data can be collected, organized, and stored
by a wide range of architecture tools developed by commercial sources. It is anticipated that
these tools will adopt the DM2 PES for the exchange of architectural data.
DoDAF V2.0 provides a Data Capture Method for each data group of the DM2 to guide
architects in collecting and organizing the necessary architectural data.
The DoDAF enables architectural content that is "Fit-for-Purpose" as an architectural
description consistent with specific project or mission objectives. Because the techniques of
architectural description can be applied at myriad levels of an enterprise, the purpose or use
of an architectural description at each level will be different in content, structure, and level of
detail. Tailoring the architectural description development to address specific, well-
articulated, and understood purposes, will help ensure the necessary data is collected at the
appropriate level of detail to support specific decisions or objectives.
Visualizing architectural data is accomplished through models (e.g., the products described
in previous versions of DoDAF). Models can be documents, spreadsheets, dashboards, or
other graphical representations and serve as a template for organizing and displaying data in
a more easily understood format. When data is collected and presented as a "filled-in"
model, the result is called a view. Organized collections of views (often representing
processes, systems, services, standards, etc.) are referred to as viewpoints, and with
appropriate definitions are collectively called the Architectural Description.
DoDAF V2.0 discusses DoDAF-described Models and Fit-for-Purpose Views:
DoDAF-described Models (also referred to as Models) are created from the
subset of data for a particular purpose. Once the DoDAF-described Models are
populated with data, these "views" are useful as examples for presentation purposes,
and can be used as described, modified, or tailored as needed.
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
3
DoDAF Introduction
Fit-for-Purpose Views are user-defined views of a subset of architectural data
created for some specific purpose (i.e., "Fit-for-Purpose"). While these views are not
described or defined in DoDAF, they can be created, as needed, to ensure that
presentation of architectural data is easily understood. This enables organizations to
use their own established presentation preferences in their deliberations.
The models described in DoDAF, including those that are legacies from previous versions of
the Framework, are provided as pre-defined examples that can be used when developing
presentations of architectural data.
Specific DoDAF-described Models for a particular purpose are prescribed by process-owners.
All the DoDAF-described Models do not have to be created. If an activity model is created, a
necessary set of data for the activity model is required. Key process owners will decide what
architectural data is required, generally through DoDAF-described Models or Fit-for-Purpose
Views. However, other regulations and instructions from the DoD and the Chairman, Joint
Chiefs of Staff (CJCS) have particular presentation view requirements.
The architect and stakeholders select views to ensure that the Architectural Descriptions will
support current and future states of the process or activity under review. Selecting
Architecture Viewpoints carefully ensures that the views adequately frame concerns, e.g., by
explaining the requirements and proposed solutions, in ways that enhance audience
understanding.
DoDAF also serves as the principal guide for development of integrated architectures as
defined in DoD Instruction 4630.8, which defines an integrated architecture as "An
architecture consisting of multiples views or perspectives facilitating integration and
promoting interoperability across capabilities and among integrated architectures". The term
integrated means that data required in more than one instance in architectural views is
commonly understood across those views.
The DM2 provides information needed to collect, organize, and store data in a way easily
understood.
The DM2 replaces the Core Architecture Data Model (CADM) which supported previous
versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the
use of data within an architecture document. CADM can continue to be used in support of
architectures created in previous versions of DoDAF. NOTE: DoDAF V2.0 does NOT
prescribe a Physical Data Model (PDM), leaving that task to software developers
who will implement the principles and practices of DoDAF in their own software
offerings.
DoDAF V2.0 is a marked change from earlier versions of Command, Control,
Communications, Computers, and Intelligence Surveillance Reconnaissance Architecture
Framework (C4ISR AF) or DoDAF, in that architects now have the freedom to create
enterprise architectures to meet the demands of their customers. The core of DoDAF V2.0 is
a data-centric approach where the creation of architectures to support decision-making is
secondary to the collection, storage, and maintenance of data needed to make efficient and
effective decisions. The architect and stakeholders select views to ensure that architectures
will explain current and future states of the process or activity under review. Selecting
architectural views carefully ensures that they adequately explain the requirement and
proposed solution in ways that will enhance audience understanding.
DoDAF V2.0 also provides, but does not require, a particular methodology in architecture
development. It provides guidance and suggestions on how to ensure that other proposed
methods can be adapted as needed to meet the DoD requirements for data collection and
storage. Similarly, the views presented in DoDAF are examples, intended to serve as a
possible visualization of a particular view. DoDAF V2.0 also continues providing support for
views (i.e., 'products' developed in previous versions of the Framework). These views do not
require any particular graphical design by toolset vendors.
Authority: Law and Policy DoDAF Supports
Federal law and policies have expressed the need for architectures in support of business
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
4
DoDAF Introduction
decisions.
Policy/Guidance
Clinger-Cohen Act
of 1996
Description
Recognizes the need for Federal Agencies to improve the way they
select and manage IT resources and states, “information technology
architecture, with respect to an executive agency, means an integrated
framework for evolving or maintaining IT and acquiring new IT to
achieve the agency’s strategic goals and information resources
management goals.” Chief Information Officers are assigned the
responsibility for “developing, maintaining, and facilitating the
implementation of a sound and integrated IT architecture for the
executive agency”.
E-Government
Act of 2002
Calls for the development of Enterprise Architecture to aid in enhancing
the management and promotion of electronic government services and
processes.
Office of
Management and
Budget Circular
A-130
“Establishes policy for the management of Federal information
resources” and calls for the use of Enterprise Architectures to support
capital planning and investment control processes. Includes
implementation principles and guidelines for creating and maintaining
Enterprise Architectures.
OMB Federal
Enterprise
Architecture
Reference Models
(FEA RM)
Facilitates cross-agency analysis and the identification of duplicative
investments, gaps, and opportunities for collaboration within and across
Federal Agencies. Alignment with the reference models ensures that
important elements of the FEA are described in a common and
consistent way. The DoD Enterprise Architecture Reference Models are
aligned with the FEA RM.
Serves as the basis for enterprise architecture maturity assessments.
Compliance with the EAAF ensures that enterprise architectures are
advanced and appropriately developed to improve the performance of
information resource management and IT investment decision making.
“Outlines the steps toward achieving a stable and mature process for
managing the development, maintenance, and implementation of
enterprise architecture.” Using the EAMMF allows managers to
determine what steps are needed for improving architecture
management.
OMB Enterprise
Architecture
Assessment
Framework
(EAAF)
General
Accounting Office
Enterprise
Architecture
Management
Maturity
Framework
(EAMMF)
Go to top of page ↑
Six Core Processes DoDAF Supports
Organizations within the DoD may define local change management processes, supportable
by Architectural Descriptions, while adhering to defined decision support processes mandated
by the Department, including JCIDS, the DAS, SE, PPBE, Net-centric Integration, and PfM.
These key support processes are designed to provide uniform, mandated, processes in
critical decision-making areas, supplemented by individual agency operations, defined by
Architectural Descriptions tailored to support those decisions-making requirements.
Joint Capability Integration and Development System
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
5
DoDAF Introduction
The primary objective of the JCIDS process is to ensure warfighters receive the capabilities
required to execute their assigned missions successfully. JCIDS defines a collaborative
process that utilizes joint concepts and integrated Architectural Descriptions to identify
prioritized capability gaps and integrated joint Doctrine, Organization, Training, Materiel,
Leadership and Education, Personnel, and Facilities (DOTMLPF) and policy approaches
(materiel and non-materiel) to resolve those gaps. JCIDS implements an integrated,
collaborative process to guide development of new capabilities through changes in joint
DOTMLPF and policy.
JCIDS process owners have written policy to support architecture requirements (i.e., specific
product sets required in specific documents, such as the Information Support Plan, Capability
Development Document, and Capability Production Document) that permits components and
lower echelon commands to invoke the JCIDS process for requirements at all levels.
Defense Acquisition System
The DAS exists to manage the nation’s investments in technologies, programs, and product
support necessary to achieve the National Security Strategy and support employment and
maintenance of the United States Armed Forces. The DAS uses Joint Concepts, integrated
architectures, and DOTMLPF analysis in an integrated, collaborative process to ensure that
desired capabilities are supported by affordable systems and other resources.
DoD Directive 5000.1 provides the policies and principles that govern the DAS. In turn, DoD
Instruction 5000.2, Operation of the DAS establishes the management framework for
translating mission needs and technology opportunities, based on approved mission needs
and requirements, into stable, affordable, and well-managed acquisition programs that
include weapon systems and automated information systems (AISs). The Defense Acquisition
Management Framework provides an event-based process where acquisition programs
advance through a series of milestones associated with significant program phases.
The USD (AT&L) leads the development of integrated plans or roadmaps using integrated
architectures as its base. DoD organizations use these roadmaps to conduct capability
assessments, guide systems development, and define the associated investment plans as the
basis for aligning resources and as an input to the Defense Planning Guidance (DPG),
Program Objective Memorandum (POM) development, and Program and Budget Reviews.
Systems Engineering
DoD Acquisition policy directs all programs responding to a capabilities or requirements
document, regardless of acquisition category, to apply a robust SE approach that balances
total system performance and total cost with the family-of-systems, and system-of-systems
context. Programs develop a Systems Engineering Plan (SEP) for Milestone Decision
Authority (MDA) that describes the program’s overall technical approach, including activities,
resources, measures (metrics), and applicable performance incentives.
SE processes are applied to allow an orderly progression from one level of development to
the next detailed level using controlled baselines. These processes are used for the system,
subsystems, and system components as well as for the supporting or enabling systems used
for the production, operation, training, support, and disposal of that system. Execution of
technical management processes and activities, such as trade studies or risk management
activities may point to specific requirements, interfaces, or design solutions as non-optimal
and suggest change to increase system-wide performance, achieve cost savings, or meet
scheduling deadlines.
Architecture supports SE by providing a structured approach to document design and
development decisions based on established requirements.
Planning, Programming, Budgeting, and Execution
The PPBE process allocates resources within the DoD and establishes a framework and
process for decision-making on future programs. PPBE is a systematic process that guides
DoD’s strategy development, identification of needs for military capabilities, program
planning, resource estimation, and allocation, acquisition, and other decision processes.
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
6
DoDAF Introduction
JCIDS is a key supporting process for PPBE, providing prioritization and affordability advice.
DoDAF V2.0 supports the PPBE process by identifying the touch points between architecture
and the PPBE process, identifying the data to be captured within an Architectural
Description, facilitating informed decision-making, and identifying ways of presenting data to
various stakeholders/roles in the PPBE decision process.
Portfolio Management
DoD policy requires that IT investments be managed as portfolios to ensure IT investments
support the Department’s vision, mission, and goals; ensure efficient and effective delivery
of capabilities to the Warfighter; and maximize return on investment within the enterprise.
Each portfolio may be managed using the architectural plans, risk management techniques,
capability goals and objectives, and performance measures. Capability architecting is done
primarily to support the definition of capability requirements. PfM uses the Architectural
Description to analyze decisions on fielding or analysis of a needed capability.
Architectural support to PfM tends to focus on the investment decision itself (although not
exclusively), and assists in justifying investments, evaluating the risk, and providing a
capability gap analysis.
Operations
In most cases, an enterprise will capture its routine or repeatable business and mission
operations as architectural content. However, when the basic structure of an activity is very
stable and the activity repeated often, such as military operations planning or project
definition and management, the enterprise may choose to include that structure as part of
the Architectural Description itself. In this case, the architecture repository may be enhanced
to include templates, checklists, and other artifacts commonly used to support the activity.
The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires
program managers to attain the right knowledge at critical junctures to make informed
program decisions throughout the acquisition process. The DoD IT PfM process continues to
evolve that approach with emphasis on individual systems and/or services designed to
improve overall mission capability. Consistent with OMB Capital Planning and Investment
Control (CPIC) guidance, the DoD uses four continuous integrated activities to manage its
portfolios – analysis, selection, control, and evaluation. The overall process is iterative, with
results being fed back into the system to guide future decisions.
Go to top of page ↑
DM2 Support for the Six Core Processes DoDAF Supports
The DoDAF V2.0 Meta-model Groups support the viewpoints and DoD Key Processes of
JCIDS, DAS, PPBE, System Engineering, Operations, and Portfolio Management (IT and
Capability). The table below indicates a non-inclusive mapping of DoDAF Meta-model Groups
to the DoDAF Viewpoints and DoD Key Processes. The support for the Key Processes is for
the information requirements that were presented at the workshops for the key processes
and, as such, do not reflect all of the information requirements that a key process could
need.
DoDAF Meta-model Groups Mapping to Viewpoints and DoD Key Processes
Metamodel
Data Groups
Performer
View Points
DoD Key Processes
AV, CV,
JCIDS, DAS, PPBE, System Engineering,
DIV,OV,PV,StdV,
Operations, Portfolio Management (IT
SvcV, SV
CV, OV,
PV,StdV, SvcV,
and Capability)
J, D, P, S, O, C
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
7
DoDAF Introduction
Activity
Resource Flow
SV
OV
AV, CV,
DIV,OV,PV,StdV
Data and Information
AV, DIV
Capability
Services
Project
Training/Skill/Education
Goals
Rules
Measures
Location
CV, PV, SV,
SvcV
CV, StdV, SV
AV, CV, PV,
SvcV, SV
OV, SV, SvcV,
StdV
CV, PV
OV, StdV, SvcV,
SV
SvcV, SV
SvcV, SV
Go to top of page ↑
What is New in DoDAF V2.0
The major changes for DoDAF V2.0 are:
J, O, C
J, S, O
J, D, P, S, O, C
J, D, P, S, O, C
P, S, C
D, P, S, C
J, S, O
J, D, P, O, C
J, D, S, O
J, D, S, O, C
P, S, O
The major emphasis on architecture development has changed from a product-centric
process to a data-centric process designed to provide decision-making data organized
as information for the manager.
Products have been replaced by views that represent specific types of presentation for
architectural data and derived information. With the focus on data, DoDAF V2.0 does
not have products but has DoDAF-described Models. Rather than the Operational
Viewpoint-5 (OV-5) Operational Activity Model Product, there is the Activity Model
with the same supporting data. This is shifting the focus of the architecture effort onto
the data early in the Architecture Development Process.
Architecture views are, in turn, organized into viewpoints, which provide a broad
understanding of the purpose, objectives, component parts, and capabilities
represented by the individual architectural views.
The three major viewpoints of architecture described in previous version (e.g.,
Operational, Technical, and System) have been changed to more specific viewpoints
that relate to the collection of architecture-related data which can be organized as
useful information for the manager in decision-making. To support customer
requirement and re-organization needs:
All the models of data—conceptual, logical, or physical—have been placed into
the Data and Information Viewpoint.
The Technical Standards Viewpoint has been updated to the Standards
Viewpoint and can describe business, commercial, and doctrinal standards, in
addition to technical standards.
The Operational Viewpoint now can describe rules and constraints for any
function (business, intelligence, warfighting, etc.) rather that just those derived
from data relationships.
Due to the emphasis within the Department on Capability PfM and feedback
from the Acquisition community, the Capability Viewpoint and Project Viewpoint
have been added.
http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]
8
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
