introduccion a dodaf

DoDAF 2.0 Modeling with IBM Rational System Architect V11.4QB138 ERC 1.0 Student Manual

IBM Corporation Rational software U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this documentation in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

Intellectual Property Dept. IBM Corporation 20 Maguire Road Lexington, Massachusetts 02421-3112 U.S.A.

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

If you are viewing this information in softcopy, the photographs and color illustrations may not appear. Trademarks and service marks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.html

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.

IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Intel trademark information

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Microsoft trademark guidelines

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office

UNIX is a registered trademark of The Open Group in the United States and other countries.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom.

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

DoDAF 2.0 modeling with IBM Rational SystemArchitect V11.4 Table of Contents

Copyright IBM Corp. 2011 i Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Contents

Module 0 Course overview Intended audience .................................................................................................... 0-2 Prerequisites............................................................................................................. 0-3 Course description ................................................................................................... 0-4 Course goals and objectives .................................................................................... 0-5 Course outline.......................................................................................................... 0-6

Module 1 Introcution to DoDAF 2.0 Module overview .................................................................................................... 1-2 Overview of DoDAF 2.0 ......................................................................................... 1-3 What is DoDAF? ..................................................................................................... 1-4 Real-world capability: Korean war lessons learned................................................. 1-5 Use of DoDAF architectures ................................................................................... 1-6 The new DoD approach to architecture: DoDAF 2.0 .............................................. 1-7 Two major themes of DoDAF 2.0 ........................................................................... 1-8 DoDAF Evolution.................................................................................................... 1-9 DoDAF Work Products ......................................................................................... 1-10 Major changes in DoDAF 2.0................................................................................ 1-11 Communicate: Fit-for-Purpose architecture descriptions ...................................... 1-12 How DoDAF 2.0 facilitates architecture usage ..................................................... 1-13 DoDAF 2.0 establishes formal architecture tiers................................................... 1-15 Informal architecture tiers...................................................................................... 1-16 Linking Formal and Informal architecture tiers..................................................... 1-17 Example of capability identification: Defend against IEDs................................... 1-18 Define the architecture scope to determine Fit-for-Purpose .................................. 1-20 Zachman Framework with architecture tiers ......................................................... 1-21 Support for DoDAF 2.0 in Rational System Architect .......................................... 1-22 Transitioning from DoDAF 1.5 to 2.0 ................................................................... 1-32 When to Transition to DoDAF 2.0 ........................................................................ 1-33 Course outline........................................................................................................ 1-35

Module 2 DoDAF 2.0 Viewpoints Module overview .................................................................................................... 2-2 The eight viewpoints of DoDAF 2.0 ....................................................................... 2-4 Overlay of DoDAF 1.5 and 2.0 ............................................................................... 2-5 DoDAF 2.0 development path................................................................................. 2-6 Physical Exchange Specification (PES) .................................................................. 2-8 Mapping DoDAF 1.5 data elements to 2.0 .............................................................. 2-9 Diagram changes ................................................................................................... 2-12 Overview of viewpoints and models ..................................................................... 2-13

Module 3 A brief overview of Rational System Architect Module overview .................................................................................................... 3-2 General Overview.................................................................................................... 3-3 Rational System Architect ....................................................................................... 3-4 Rational System Architect workspace ..................................................................... 3-5 Open or create a new database................................................................................. 3-8 Configure encyclopedia properties .......................................................................... 3-9


Copyright IBM Corp. 2011 ii Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Configure session options...................................................................................... 3-10 Set drawing and interaction preferences................................................................ 3-11 Case study.............................................................................................................. 3-12 Configure for DoDAF 2.0 modeling ..................................................................... 3-15 Exercise 1 .............................................................................................................. 3-17 Representational Consistency................................................................................ 3-18 References ............................................................................................................. 3-21 Diagrams and relationships.................................................................................... 3-29 Inheritance ............................................................................................................. 3-38 Summary................................................................................................................ 3-44 Course outline........................................................................................................ 3-45

Module 4 Creating DoDAF 2.0 operating models Module overview .................................................................................................... 4-2 DoDAF 2.0 models support in Rational System Architect...................................... 4-3 DoDAF 2.0 Development Path, highlighting supported models ............................. 4-4 DoDAF described models........................................................................................ 4-7 Developing DoDAF models via a development path .............................................. 4-8 AV-1: Overview and Summary information ......................................................... 4-10 CV-1- Capability Vision........................................................................................ 4-14 Exercise 2 and 3..................................................................................................... 4-18 OV-1 High level operational concept ................................................................. 4-20 Exercise 4 .............................................................................................................. 4-22 OV-5 Operational Activity Model......................................................................... 4-24 OV-5b Operational Activity model ....................................................................... 4-29 Exercise 5 and 6..................................................................................................... 4-30 Exercise 7 and 8..................................................................................................... 4-36 OV-4 Organizational Relationships Chart............................................................. 4-38 Exercise 9 (Optional)............................................................................................ 4-39 OV-6a Operational Rules Model ........................................................................... 4-41 OV-6b State Transition Description ...................................................................... 4-42 OV-6c Event-Trace Description ............................................................................ 4-43 Optional: Exercise 10, 11, 12 ............................................................................... 4-45 SvcV-4 Services Functionality Description .......................................................... 4-51 Exercise 13, 14 (Optional).................................................................................... 4-54 Exercise 15 ............................................................................................................ 4-58 Exercise 16 (optional)............................................................................................ 4-61 OV-3 Operational Resource Flow Matrix ............................................................. 4-70 CV-5 Capability to Organizational Development Mapping .................................. 4-71 CV-6 Capability to Operational Activities Mapping ............................................. 4-72 CV-7 Capability Service Mapping ....................................................................... 4-73 SV-5a Activity to system matrix ........................................................................... 4-74 SV-3 Systems to Systems Matrix .......................................................................... 4-75 Svc-3a Systems to services .................................................................................... 4-76 Exercise 17 ........................................................................................................... 4-77 SV-4 Systems Functionality Description............................................................... 4-80 Exercise 18 and 19 (optional) ............................................................................... 4-82 SV-1 Systems Interface Description...................................................................... 4-84 Exercise 20 (optional)........................................................................................... 4-85 SV-2 Systems Resource Flow Description............................................................ 4-87


Copyright IBM Corp. 2011 iii Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Exercise 21 (optional)............................................................................................ 4-88 Div-2 Logical Data Model (Conceptual) ............................................................... 4-90 Div-3 Physical Data Model ................................................................................... 4-99 Exercise 22, 23 (optional)................................................................................... 4-100 Module summary ................................................................................................. 4-101

Module 5 DoDAF 2.0 Reporting Module overview .................................................................................................... 5-2 The Report Generator reports .................................................................................. 5-3 Graphical user interface........................................................................................... 5-4 Explorer diagrams.................................................................................................... 5-5 Populating the explorer diagram.............................................................................. 5-6 Reporting on Explicit relationships - metamodel .................................................... 5-8 Report Keyword: NAMEONLY............................................................................ 5-10 Reporting on Instancing......................................................................................... 5-11 Exercise 24,25, 26, 27, 28 ..................................................................................... 5-12 Summary................................................................................................................ 5-13

Module 6 Summary and next steps Course summary ...................................................................................................... 6-2 The complete enterprise offering............................................................................. 6-3 Further information ................................................................................................. 6-4 Course survey .......................................................................................................... 6-5


Copyright IBM Corp. 2011 iv Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

DoDAF 2.0 modeling with IBM Rational SystemArchitect V11.4 Module 0 - Course overview

Copyright IBM Corp. 2011 0 -

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

Copyright IBM Corporation 2011

DoDAF 2.0 Modeling with IBM Rational System Architect V11.4Module 0: Course overview

ContentsIntended audience 0-2Prerequisites 0-3Course description 0-4Course goals and objectives 0-5Course outline 0-6




2

2 Copyright IBM Corporation 2011

Intended audiencePrimary target audience:

System and software engineers Enterprise architects and engineers

Secondary target audience: Program or project managers Development team leads Software designers and testers




3


PrerequisitesTo benefit from this course, students should have the following skills and experience, or have taken the following Rational courses:

Experience creating DoDAF 1.5 work products, or DoDAF 2.0 described models

Working knowledge of IBM Rational System Architect

Courses: (QB133/HQ133/QBV32) Fundamentals of IBM Rational

System Architect




4


Course description This course provides an architectural overview of DoDAF 2.0

modeling with IBM Rational System Architect, V11.4. The course focuses on these items : The basic theory of DoDAF 2.0 The eight viewpoints of the DoDAF 2.0 architecture The levels of formal and informal architecture The mapping of new DoDAF 2.0 data elements to previous DoDAF data

elements Support for DoDAF 2.0 in Rational System Architect Transitioning from DoDAF 1.5 to DoDAF 2.0 Suggested DoDAF 2.0 development path Creating DoDAF-described models Analyzing and reporting on DoDAF models




5


Course goals and objectivesAfter you complete this course, you will be able to

explain and demonstrate how to use Rational System Architect to do the following things : Model DoDAF 2.0 described models

Capability modeling Operational modeling Systems/Services modeling

Manage change across the DoDAF-described models Perform analysis on DoDAF models Report on information in the encyclopedia Collaborate with your team and stakeholders




6


Course outlineModule 0: Course overviewModule 1: Overview of DoDAF 2.0Module 2: DoDAF 2.0 viewpoints Module 3: A brief overview of

Rational System Architect

Module 4: Creating DoDAF 2.0 modelsModule 5: DoDAF 2.0 reportingModule 6: Course summary and next steps

This course is a combination of lecture and exercises.Exercises: Case study: Unmanned Aerial Vehicle (UAV)




7


Course outlineModule 0: Course overviewModule 1: Overview of DoDAF 2.0Module 2: DoDAF 2.0 viewpoints Module 3: A brief overview of







8


DoDAF 2.0 modeling with IBM Rational SystemArchitect V11.4 Module 1 - Introcution to DoDAF 2.0



1


DoDAF 2.0 Modeling with IBM Rational System Architect V11.4Module 1: Overview of DoDAF 2.0

ContentsModule overview 1-2Overview of DoDAF 2.0 1-3What is DoDAF? 1-4Real-world capability: Korean war lessons learned 1-5Use of DoDAF architectures 1-6The new DoD approach to architecture: DoDAF 2.0 1-7Two major themes of DoDAF 2.0 1-8DoDAF Evolution 1-9DoDAF Work Products 1-10Major changes in DoDAF 2.0 1-11Communicate: Fit-for-Purpose architecture descriptions 1-12How DoDAF 2.0 facilitates architecture usage 1-13DoDAF 2.0 establishes formal architecture tiers 1-15Informal architecture tiers 1-16Linking Formal and Informal architecture tiers 1-17Example of capability identification: Defend against IEDs 1-18Define the architecture scope to determine Fit-for-Purpose 1-20Zachman Framework with architecture tiers 1-21Support for DoDAF 2.0 in Rational System Architect 1-22Transitioning from DoDAF 1.5 to 2.0 1-32When to Transition to DoDAF 2.0 1-33Course outline 1-35




2


Module overview After you complete this module, you will be able to state the following things : Why DoDAF was created Differences between DoDAF 1.5 and 2.0 What is new in DoDAF 2.0 How Rational System Architect supports DoDAF 2.0 How to transition to DoDAF 2.0 strategies




3


Whats next?> Overview of DoDAF 2.0Support for DoDAF 2.0

in Rational System ArchitectTransitioning from DoDAF 1.5 to 2.0

> = Current topic




4


What is DoDAF?Department of Defense Architecture Framework

Facilitates key decision making through organized information sharing

Generally conveys a conceptual modeling language

Mandated by DoD Acquisition regulations




5


Real-world capability: Korean war lessons learned Lessons learned from the Korean war produced two

new capabilities for the US Department of Defense:1. Ability to fly missions at night2. Ability to take off and land during inclement weather

An example of planning for capabilities can be seen when reviewing the lessons learned of the Korean war. Two new capabilities were identified. One was the ability to fly missions at night. The second was the ability to take off and land during inclement weather.Traditionally what used to happen is that, as an example, the Air Force would develop a system to fly at night because thats where they saw a gap in their capabilities, and the Navy would develop a system to take off and land in inclement weather, because thats where the Navy saw a gap in their capabilities. There wasnt a way for someone in the Air Force to know about the Navys project unless they heard by word of mouth, so the development of these new functions occurred in isolation. And, when the Air Force realized they needed the capability to take off and land in inclement weather, they would build their own system without reusing the work the Navy had done. Or worse, the Air Force might find out the Navy had a system for take off and landing in inclement weather, but the way the two systems were designed was so specified to one capability, or so poorly documented, that building new systems from scratch was easier than reusing what was already built.In todays environment, delays in providing needed capabilities to support troops in an operational theater is not acceptable. Funding for projects is limited. DoDAF 2.0 aims to address these issues so that capabilities can be identified and planned for, information will be available and reusable across projects (and that includes joint projects and not just projects specific to one organization in the DoD), and system integration will be seamless. Fit-for-Purpose architecture ensures that only the information needed to engineer a problem solution is created and analyzed, which speeds the capability development process. A change in one project that can impact multiple projects, such as a service or system delivery slippage, can be identified and managed.




6


Use of DoDAF architecturesCapability-based planningWhat are the key capabilities? Which projects support which capabilities?Who is working on what capabilities?Which projects will get funding?

Capability support planningWhat is the business of the DoDcomponent and which capabilities does it require? What are the tactical operations? What are support procurement decisions? What are the standards and constraints that govern?

Portfolio managementApplication portfolio managementResource alignmentImpact of change

System and service managementSpecify interfacesCapture needed functionalityIdentify interoperability Support acquire or develop decisionsCom

ponent

archite

ctures

----------

----------

Segmen

t

archite

ctures

----------

----------

Departm

ent

archite

ctures

----------

---------- Enablement

Training

In the department of defense, architecture provides visibility into how and why the business works and improves decision making. Stakeholders can act on information because they understand its context within the architecture framework. An architecture program helps to document, analyze, and plan.

There are many reasons why an architecture might be created, from capability-based planning, to portfolio management, to training, and more. Architectures are not the final product. Architectures facilitate key decision making through organized information sharing, that will be interpreted, and support strategic decisions. DoDAF provides guidance for all the architectures developed, maintained, and used within the department of defense, which enables the sharing of all pertinent architecture information.




7


The new DoD approach to architecture: DoDAF 2.0Funding is driven by capabilities to ensure that the

DoD can respond to events today and in the future Provides more flexibility and the ability for the decision

maker to analyze change impact Shows how joint forces can address the ability to meet a

capabilityProjects to meet the capabilities can be modeled Provides insight into funding allocations Allows for planning Identifies gaps

Architecture is now Fit-for-Purpose

DoDAF 2.0 represents a new approach to architecture. In the past, funding was given to programs that could show that their technical approach was feasible. Now funding is driven by capabilities. This change was escalated in part because of the wars in Iraq and Afghanistan, when the DoD struggled to quickly develop capabilities focused more on fighting an asymmetrical war.

Having capabilities drive architecture provides flexibility and change impact analysis for the decision maker. For example, an event might trigger changes in the priorities of capabilities, or it might identify a new capability. The capability is then assigned to one or more organizations for development to ensure that it is ready when needed. Also, this enables the joint chiefs to plan for capabilities that the DoD needs in the future, to assign those capabilities to one or more organizations for development, and to make sure that technology is being developed to meet those capabilities when they are needed.

Projects are more closely aligned, and this enables organizations and the joint staff to see which projects are a priority for funding, which projects need to be planned for the future, and the impact if a project fails to deliver on time. Projects can span not just an organization, but also the entire DoD; so, for example, the relationship between a project done at the US Air Force and one done at the US Navy can be modeled for dependencies.

Architecture is now Fit-for-Purpose, meaning that a specific set of models is not required to get funding. You only develop the models that are needed for your project.




8


Two major themes of DoDAF 2.0DoDAF is data centric, not product centric Allows for tool-agnostic and model-agnostic sharing of

architecture data Provides for a process to collect the right data, for the right

requirement, the right way, to meet the needs of the decision maker

Fit-for-Purpose ensures that the architecture contains only the data needed for the requirement, and uses only the views and models that are necessary Why is the architecture being created? How will the architecture be used? What is the scope of the architecture?

There are two major themes of DoDAF 2.0.By having a data centric approach to architecture, modelers are not limited to using a specific modeling tool. Any modeling tool that supports DoDAF 2.0 can be used to create architecture. This also means that architecture data can be more easily shared. By focusing more on data, the modeler is also now collecting information in a standardized way to ensure the right data is being collected in the right way for the needs of the decision maker.

Fit for Purpose means the architecture development process is streamlined to create only the needed models and views for the problem at hand. The questions that need to be answered to identify what those models are, are as follows:Why is the architecture being created? For example, are you building a specific set of services to move data in an operational theater, or are you defining the operational environment of a new capability( for example, how will the US Coast Guard defend the US coast line)? How will the architecture be used? So , is it being created for implementation (were going to build these services), or is it a future state for an organization (what will the US Navy look like in 10 years and what will the required skills be for its people)? What is the scope of the architecture? Is it an enterprise architecture (heres a high-level look at the US Marines and their capabilities), or is it for a component (I need to build a system to manage logistics)?




9


DoDAF evolution

System View

AV, DIV, CV, OV, SvcV, SV, PV

AV, SV

,

OV, TV

52 DoDAF described views

30 wo

rk

produc

ts

Data and information viewpoint

SV-1,

OV-7

TOGA

F

NAF

MODA

F

DM2

This slide shows the evolution of DoDAF.The original views (All View, Technical View, System View, Operational View) were reorganized in DoDAF 2.0 to better address their purpose, and are now called Viewpoints. A collection of viewpoints is called an Architectural description.The keyword products have been replaced by DoDAF described models or simply models. DoDAF 2.0 has 8 views and 52 models, so it has 4 more views than version 1.5 and more models, such as Capability models and Project models. DoDAF 2.0 allows the ability to add more Fit-for-Purpose views. Some of the models have been renamed, but arent new. For example, the OV-7 and SV-11 are in their own view, called the data and information view, and have been renamed to DIV-2 and DIV-3.Some models have the same name, but the content is different. The OV-2 does not have an operational node any more. The needlines have been expanded to include Material, Personnel, and Funding flows and the diagram is now meant to show the operational delivery of a specific capability.Relationships between data elements in the metamodel have changed to provide a better ability to answer questions with the architecture. The metamodel underpinning DoDAF 2.0, called the DM2, is very different than the metamodel used for earlier versions of DoDAF (which actually only existed informally) and introduces new elements, such as project and performer. There are also new linkages and relationships between the elements of DoDAF 2.0, such as an organizational resource linking to a capability.The new standards view has been expanded from only technical standards and can address business, commercial, and doctrinal standards. The operational view products have been extended to include information such as the performers of an activity and resource flows going to and from those activities. The services view was separated from the systems view. The systems view will eventually retire as new components are designed as services rather than stand-alone systems.Services have been separated into their own view, with the idea that the system view will eventually be retired.Capabilities and project information are now addressed in response to the acquisition communitys needs. New capability viewpoints and project viewpoints were added. Capabilities and project information are now addressed in response to the acquisition community needs.DoDAF 2.0 introduces a definition for different levels of architecture, which provides some guidance as to how to manage an architecture created at the enterprise level, and then further detailed in lower-level architectures at the solution level, as well as the guidance to only develop what is needed to solve the problem at hand. This is referred to as Fit-for-Purpose.




10


DoDAF 1.5 versus DoDAF 2.0

Non-contradicting across the setNo models (or work product) can exist in isolation

View, or set of models, should form an integrated architecture

Some are Diagrams or sets of diagrams Tables Timelines Different presentations of the data from another work product

Representation of DoDAF described models (previously referred to as work products)

Organized into 8 Viewpoints All View (AV) Data and Information Viewpoint (DIV) Capability Viewpoint (CV) Operational Viewpoint (OV) Services Viewpoint (SvcV) Standards Viewpoint (StdV) Systems Viewpoint (SV) Project viewpoint (PV)

52 DoDAF-described models(work products) total, with the ability to add more Fit-for-Purpose views

Organized into 4 Views All View (AV) Operational View (OV) System View (SV) Technical Standards View (TV)

30 work products total

Organization

DoDAF 2.0DoDAF 1.5

DoDAF 2.0 enables the common understanding and the reuse of information, architecture artifacts, models, and viewpoints. It outlines a series of DoDAF described models, and allows additional Fit-for-Purpose views that visualize the architectural data.

Rational System Architect assures an integrated model that maintains data integrity through its repository and a single source of data creation. DoDAF work products are integrated into Rational System Architect and changes that are made to an artifact affect the model as a whole.




11


Major changes in DoDAF 2.0 Architecture development is more focused on information centric

processes rather than product centric processes

Viewpoints have been added to more clearly organize architecture data Closer alignment with MoDAF, NAF, and TOGAF

The term product has been replaced with models and views Requirements for sharing data across a federated environment are

described

Introduction of the DoDAF Metamodel (DM2) Introduction of inheritance in DM2 and instance modeling

Tiers of architecture are identified (Department, Segment/Capability, Component, Solution)

Links to the Federal Enterprise Architecture (FEA) are described Better examples of models will be provided

There are many changes in the guidance for architecture in 2.0. Development is more focused on the information rather than the models themselves. That

means tabular views such as the OV-3 are very important, as well as the model elements (for example the properties of an activity).

The views more clearly organize the architecture data. For example, the data models have their own view now, instead of being split between the OV and the SV. There is also closer alignment between the DoDAF and other industry standard frameworks such as MoDAF, NAF, and TOGAF.

The term product is not used any more. Models describe diagrams and views describe a collection of models.

Requirements for sharing data across a federated environment are described, and Physical Exchange Specification (PES) will help facilitate data sharing by defining a common format through a formal metamodel, referred to as the DM2. This will be discussed later in the presentation. For those familiar with CADM, PES is like CADM but much more comprehensive.

The DM2 guides architects in defining and organizing architectural data. It also defines new artifacts and relationship types that did not exist in earlier versions of DoDAF. A new standard, DM2 Physical Exchange Specification (PES) will be used to interchange data from a variety of tools where the architectural model will be stored

Inheritance and instance modeling will be covered later in the course. The tiers of the architecture are identified, as well as the informal architecture tiers. Links to the Federal Enterprise Architecture are described for those organizations that use

FEA, and better examples of the DoDAF 2.0 diagrams will be provided to give modelers guidance on what the diagrams should contain and how to use the diagrams.




12


Communicate: Fit-for-Purpose architecture descriptions

Image from Volume II, Figure 1.2-1

Architectural information must be collected and presented in an effective way, focusing on the different stakeholders at different levels of the decision-making process.The architecture information can be found in several different tools, and captured in several different presentations. The architectural information must be accessible and able to be presented at the appropriate scope. Senior-level executives, process owners, and system developers have different requirements for the presentation of data, and might need to look at the same information, in various formats and levels of detail. When deciding on the presentation, you must consider the purpose of the information and the audience. For presentation, you can use either DoDAF-described models or, alternatively, Fit-for-Purpose views.

12




13


How DoDAF 2.0 facilitates architecture usageDoDAF 2.0 is data centric, not

product centric DoDAF 2 Metamodel (DM2) precisely

defined The term product has been replaced

with models and views Allows for tool-agnostic and model-

agnostic sharing of architecture data Diagrams do not hold information;

they reflect information of the architecture at all times

Provides a process to collect the right data, for the right requirement, the right way to meet the needs of the decision maker Diagrams become templates for

information capture

DM2 conceptual data modelImage from Volume II, Figure 2-1

DoDAF 2.0 has introduced the DoDAF Metamodel (DM2) and DM2 Physical Exchange Specification (PES), which allows for tool-agnostic and model-agnostic sharing of architecture data.DoDAF-described models are supported by the DM2 PES.

DoDAF 2.0 provides a 6-step Architecture Development Process that helps collect the right data for the right requirement for a particular purpose.




14


DoDAF 2.0 data-centric architecture facilitates information exchange

Physical Exchange Specification (PES) provides the following benefits: Architecture information is tool agnostic Architecture data is easy to reuse and share Data is methodology agnostic

PES can be used to build federated architectures that share common data elements

PES is accomplished using XML Schema Definitions (XSDs) for each model (Example: CV-2)

CADM is no longer used to exchange architecture data

PES XSD, PES XML, XMI, UML, and SysML RelationshipsImage from Volume III, Figure 4-2

CADM is being retired. PES, which is based on the DM2, will be used to exchange data between architecture projects. This means that architecture information is tool agnostic, and you can pull architecture information from one tool into another as long as they both support PES. Architecture data will be more easily shared and reused because a standard format is used. Data is also methodology agnostic, meaning, for example, a project that creates the OV-5 using a use case can exchange data with a project that created an OV-5 using IDEF 0.

PES will be used when architecture information needs to be pushed from a department level to a capability and solution level, and can be used when two architecture projects share common data elements. It will also be used to share architecture data across the whole DoD. PES works from an XML schema that is created for each model.

The DoDAF 2.0 specification documents in a table the movement of DoDAF 1.5 data to 2.0, as well as the mapping from CADM to the new DM2.




15


DoDAF 2.0 establishes formal architecture tiersDepartment-level architecture Describes processes at the department or Joint Staff level Includes the Global Information Grid (GIG) and DoD

Information Enterprise Architecture (DoD IEA)Capability, or segment, architecture Defines and describes specific capabilities that are required

for business, procurement, and tactical operations Referred to as a segment architecture in OMB Circular A-130

Component architecture Defines and describes the business and operational functions

of components within the DoD

There are 3 formal architecture tiers defined in DoDAF 2.0.

These three levels help control the model elements in the architecture to create a standard use of terminology. For example, organizational units are defined at the department level. When a capability-level architecture is created, it should reuse the organizational units defined already at the department level. That will make modeling faster and more accurate. It will also provide the ability at the department level for a decision maker to query common data that is used in multiple capability or solution architectures. The advantage is that, for example, if an organizational unit is being renamed, eliminated, or reorganized, the impact can be assessed across the whole enterprise, rather than the situation that is common today, wherein a change occurs in one department and breaks something in another department.

The Department-level architecture provides governance for the other two tiers. Its developed at the organizational level or the joint staff level; so, for example, it could be an architecture for the whole US Coast Guard or a department of the Coast Guard such as Logistics. It should include the global information grid and the DoD Information Enterprise architecture to ensure that the requirements and dependencies are taken into account in lower-level architectures. The department-level architecture is where the vision and mission is defined.

The capability or segment architecture describes the use of specific capabilities for business (for example, how Logistics does its day-to-day job), procurement (for example, which components or services must be procured to meet the Logistics departments assigned capabilities), and tactical operations (for example, defining an architecture to describe how Logistics supports operations for national security). This architecture explains how day-to-day business is done either for a specific organizational unit, or for a specific environment (for example, fighting a war in Iraq).

The component architecture looks at a specific need (for example, when performing operations for national security, which systems or services are needed in Logistics). This is where the supporting technologies and services for the operational environment are defined. The component architecture shows either which new services and technologies are needed to support operations, or which services and technologies are currently being used. This is the traditional project architecture, or solution architecture.




16


Informal architecture tiersOperational architecture Describe business or tactical operations

Systems architecture Describe systems, networks, and communications

capabilities to support operationsServices architecture Describe internal and external service capabilities

Solution architecture Define and describe future changes to a baseline architecture

There are four informal architecture tiers that are used to define, at each formal tier, which type of architecture is being created.An operational architecture describes the business/tactical operations and and focuses on the capability view, project view, and operational view.A systems architecture describes the systems, networks, and communications capabilities and focuses on the system view and the standard view. It should be based on the operational architecture.A services architecture describes internal and external service capabilities and focuses on the service view and the standard view. It should be based on the operational architecture.An architecture might have both a system and service architecture when transitioning to a service-oriented environment. In DoDAF 2.0, its highly unlikely that an architecture will be created that doesnt look at services.A solution architecture looks at an existing architecture and determines, in the future, which changes must be made. It uses all the views that are necessary to define the solution.

If the systems and services architecture do not rely on an operational architecture, there is a huge risk that technology is driving operations instead of operations driving the technical solution.




17


Linking formal and informal architecture tiers

Department-levelArchitecture

Capability/Segment Architecture

Component Architecture

Operational Architecture

SystemsArchitecture

Services Architecture

Informal architecture types can exist at any level of the formal

architecture

Solution Architecture

The informal architecture types can exist at any level of the formal architecture. Using Fit-for-Purpose you can determine which informal architectures are needed for the formal architecture tier that you are modeling. The department level will have the operational architecture and the services architecture. It might have some of the systems architecture.The capability/segment level will take the operational architecture from the department level, and add details. It should also include the services and systems architecture, although these will not be modeled in great detail. It might contain some information from the solution architecture, but it should not be solution- specific because a segment typically has multiple solution architectures related to it. Its rare, for example, for a line of business, such as logistics, to only have one project occurring.The component architecture focuses on the solution architecture, but the solution must be created within the bounds of the operational, system, and services architecture. Otherwise, there is no traceability from the component architecture to the department-level architecture.

Another fictional example shows how these tiers interact to meet a required capability.




18


Example of capability identification: Defend against IEDs

Conflicts against terrorists might require a new capability Defend against an improvised explosive device (IED)

Robots (Marines: planned) Armor plating (Army: current) Intelligence (Intelligence agency:

current, but not shared)What is important, is the

capability-based architecture Informal tiers (operational, systems, and more) provide

navigation of the capability through the architecture

In a completely fictional example, a conflict with terrorists that use improvised explosive devices (IEDs) might produce a new capability to defend against IEDs. This capabilitis required immediately for an operational environment, so it is important to use any existing assets to meet the capability because there is no time to build something new.This example shows why flexibility and gap analysis are so important. The joint chiefs need a way to look across all the organizations in the DoD to see if anyone currently has the ability to meet these two new capabilities. If not, they need to fund projects that can address these new capabilities and manage the development across multiple organizations. Different organizations in the DoD might be required to solve the IED problem, and thats why showing the dependencies between projects and capabilities at the enterprise level is so important. For example, the Marines might have a planned solution to IEDs, robots, but that project is not ready to deliver. The Army currently has an armor-plating project underway that is completed for their vehicles but never tested on a robot. And the intelligence agency has information, but it is currently not sharing it with any organizations.

DoDAF 2.0 can be used to show how, in this instance, the Marines project to build a robot to detect an IED will receive more funding to push for a faster delivery. Meanwhile, the Army currently has an armor-plating system in place to protect it. The Marines can work with the Army to strengthen the robot to ensure that when it is delivered into the operational theater, it will work. The joint chiefs can track how effective the plating is against IEDs to see if that is a capability that can be shared with other organizations in the DoD that are operating in the war zone but that have not yet had a problem with IEDs. (For example, in the future, IEDs might be retrofitted to attack ships, so the Navy would get involved to see if they can use the armor plating to protect their ships. This can be done quickly because the armor already exists, and they are being proactive before the terrorists realize there is a vulnerability.)

Finally, the intelligence agency has information about which routes have potential for an IED attack, but they do not have a way to share this information with the Army and the Marines. Using DoDAF 2.0, the information-sharing environment is modeled and understood so that information can get to the right person, at the right time, to help them make decisions this is captured in the OV-2. In this case, the intelligence agency might run a report that would show, based on the classification level of the intelligence, what can be shared with the Army and Marines. The identification of this data, if an architecture is in place, should take minutes, not months.




19


Example continued




MARINES




ARMY




INTELLIGENCE AGENCY

JOINT CHIEFS

Using formal architecture tiers to manage architecture

You might ask, how do the formal architecture tiers help in this real-world scenario to solve a problem quickly?

Here is an example.

To accomplish the mission of defending against an IED, the joint chiefs look at the capabilities of the Marines, Army, and the intelligence agency. The capability information at the department level of their architectures, which is the level that the joint chiefs look at, is consistent with the data that is developed at the capability segment and solution level, because each level takes higher-level data from the previous architecture.

To solve the IED problem, the component architectures share information to make ensure that their solutions are synchronized. If required, collaboration between the three organizations can occur at the capability/segment level, or even at the department level (for example, getting the intelligence agency to share its data might require communications from the highest level of each department).

By architecting this way, the joint chiefs can easily respond to new threats and identify gaps. The decision makers at each level have the information that they need (for example, the Marine project might need extra funding to accelerate its development, and that is facilitated by the department). Every organization understands that their failure to meet requirements or deliver on time can result in a gap for the solution to meet a capability, and a workaround can be put in place.




20


Define the architecture scope to determine Fit-for-Purpose

For each formal tier, which informal tiers should be modeled? Intended use of the architecture Boundaries of the architecture Data categories needed for analysis and decision making Key players and stakeholders (internal and external) Goals and objectives Level of complexity External requirements

This presentation demonstrated how the formal tiers can be used in the real world. The informal tiers are just as important to ensure that high-level decision makers have the data they need to solve a particular problem. Answer these questions to determine, for each formal tier, which informal tiers to model.Intended use of the architecture: What will be done with the architecture? Is it for an acquisition, planning, or for a project where services will be developed for use in an operational environment?Boundaries of the architecture: Is the architecture specific to a project, is it for a department, or is it a joint project?Data categories needed for analysis and decision making: Do you need to understand only operational data, or also the data that will be exchanged between systems or services? Is the focus at an enterprise level or for a specific project? Key players and stakeholders (internal and external): Will data need to be shared with external stakeholders who have a dependency on your architecture? Who is the architecture being developed for? Goals and objectives of the effort: Is the goal to produce an RFP, to build a system, to create a service-oriented architecture, or to improve business processes? Level of complexity needed in the data and information presentation: Is the data going to require quantitative analysis, or is only a high-level picture needed? External requirements that might influence the architecture: Could the capabilities that are being addressed in the architecture change? Are the capabilities in the architecture dependent on other capabilities that might not be developed yet? Will a change for one organization in the DoD cause a change in another organization?




21


Zachman Framework with architecture tiers

Volume 2, table 1.2-3The columns in the Zachman Framework answer six basic questions :what, how, where, who, when, whyThe higher rows are more general; the lower rows are more detailed .The Zachman Framework represent a holistic view of the enterprise in six distinct model types. Each model type is associated with a role. Each model type has artifacts that display data (what), functions (how), networks (where), people (who), time (when), and motivation (why). This information is presented in a matrix format. Each cell in the matrix presents the information based on a stakeholders perspective for a specific purpose. DoDAF V2.0 supports the needs of various stakeholdersby supporting various levels of abstraction and granularity.




22


Whats next?

> = Current topic

Overview of DoDAF 2.0>Support for DoDAF 2.0

in Rational System ArchitectTransitioning form DoDAF 1.5 to 2.0




23


Rational System Architect 11.4 support for DoDAF 2.0DoDAF 2.0 support Previously, two choices were available for DoDAF 1.5:

DoDAF Standard DoDAF ABM, with metamodel and utilities based on the

Activity Based Methodology (ABM) from MITRE For Rational System Architect 11.4, one DoDAF 2.0

implementation is available with a new metamodel Users can still model with DoDAF 1.5 Standard or DoDAF

1.5 ABM to continue work on existing projects Conversion from DoDAF 1.5 to DoDAF 2.0

A direct translation between DoDAF 1.5 and DoDAF 2.0 is not possible because the metamodel changed, links changed, items were eliminated, and views were added

Some aspects of DoDAF are best developed with other notations, for example:Business Process Modeling Notation (BPMN)Unified Modeling Language (UML)Data modeling

Rational System Architect supports such notations, which enables you to build your architecture as necessary.




24


How Rational System Architect supports DoDAF 2.0 Direct implementation of the DoDAF metamodel Representational consistency

Instance modeling

New relationships keep definition properties and models synchronized Implicit Explicit Inferred

Inheritance

Rational System Architect implements DoDAF 2.01 Metamodel (DM2) directly. Rational System Architect implemented the metamodel as it is described in the standardRational System Architect supports a data centric model. The model that is captured in the tool, is data centric, with diagrams reflecting model information. It also support the new Service and Capability views, as well as Fit-for-Purpose Views. The Rational System Architect Representational Consistency feature ensures that diagrams only present relationships that exist, according to the content of the definition. The underlying data model is updated as relationships are adjusted in the diagram. Diagrams are updated when they are opened. Multiple users are supported with a manual refresh action so that, after they are opened, diagrams do not change to reflect the underlying data model until requested.

You can use instance modeling to create a base definition, and then create instances from that base (for example, a performer of Mechanic can have multiple instances F-16 Mechanic, C-130 Mechanic). You can also represent individuals as well as types (for example, Fred is an instance of type Fighter Pilot; he has value Captain for attribute of Rank).

Implicit relationships are those based on a reference property from one item (a definition for example) to another.Explicit relationships are those based on a definition with reference properties to a source and target item (a definition for example).Both can be represented on diagrams with symbols.Inferred: A relationship determined from the existence of other relationships, for example if A is related to B and B is related to C, A can be said to be related to C. You can added inferred relationships to diagrams by using Explorer Relationship reports as visual indicators of relationships.

With inheritance support, definitions can inherit properties from other related definitions.Rational System Architect supports supertyping and subtyping in the metamodel (for example, Performer, System, and Materiel, are all types of Resources that inherit properties and behavior). You can associate any kind of Resource to any kind of Resource. You can have a matrix of Resource versus Resource.




25


Representational consistency =Model-based behavior= Data centricExplicit relationships

Intersectiondefinitions:Matrix Cell

or Line

Definition 2Definition 1

Explicit relationships Relationships between definitions that are supported by a definition

Relationships can be used in diagrams to represent lines Lines are rendered automatically where model relationships exist Equivalent to Matrix Cell definition supporting the intersection of a matrix

(Text-in-cell matrix)




26


Representational consistency= Model-based behavior= Data centric

Property in Definition 1

Definition 2Definition 1Implicit relationships

Implicit relationships Reference properties in a definition can be described as an implied relationship to

another definition. Example: An Activity has a list of Resources. An implied relationship exists

between the Activity and the Resource. (x-in-cell matrix, or ListOf or one of definition property) This relationship has no definition to actually support it.

These reference relationships can be used in diagrams to represent lines. Lines are rendered automatically where model references exist. Another example of this implicit relationship, is the between the architecture and the

projects. Note how this information is captured on the Scope tab of the architecture description




27


Representational consistency= Model-based behavior= Data centric

Inferred relationships

Inferred relationships: Run an Explorer Relationship Report to skip several definitionsto show a relationship.




28


Data centricity = Representational consistency= Model-based behavior

DM2 is a data-based metamodel Views reflect the model Model views are

consistent between diagrams

Diagrams offer true data-based input to the model

Values and benefit: Representational consistency, an extremely customizable metamodel, and customization with Microsoft Visual Basic for Applications makes Rational System Architect thearchitecture tool




29


Inheritance DoDAF 2.0: Heavy use of

metamodel inheritance Multiple inheritance All definitions ultimately inherit

from a base definition DM2 is based on the IDEAS

framework, which has the artifact type Thing at the top of the metamodel hierarchy. All other DM2 artifact types inherit from Thing.

International Defense Enterprise Architecture Specification (IDEAS)The Thing definition type is specified in the Rational System Architect metamodel (in the dodaf2.cfg file, part of the saprops.cfg property set), but Thing is not instantiated as a definition type that you model in the tool.




30


Inheritance Definition types can inherit properties from other definition

types, and can also inherit behavior, in terms of relationships that can be drawn to the symbols that represent other definition types in a diagram.

Example: Performer inherits from Resource. Therefore:Performer property set is inherited from the Resource property set. Any relationship line that can be drawn to or from a Resource, can also be drawn to/from any of its subtypes.

For example, on an OV-2 Alternative diagram, you can draw an ActivityChangesResourceline from an Activity to a Resource, or to a Performer, or to any of Performer's subtypes, such as Person.




31


Instance modelingSome types of model objects are described as

instantiatable. This means that they can have instances created from them.




32


Whats next?

> = Current topic

Overview of DoDAF 2.0Support for DoDAF 2.0

in Rational System Architect>Transitioning from DoDAF 1.5 to 2.0




33


When to transition to DoDAF 2.0

DoDAF 2.0 is mandated for new Department of Defense projects

Transitioning to Service-Oriented Architecture (SOA) Clearer guidance on modeling services Enterprise Service Bus is easier to model Global Information Grid

Funding is capability driven Modeling of capability hierarchies Modeling dependencies between capabilities

Clearer approach to aligning FEA and DoDAF




34


ImplementationTransitioning from DoDAF 1.5 Operational View models must be updated Service and System models are similar OV-7 and SV-11 transitioned to DIV Standards are enhanced to cover standards outside of IT Capabilities

New to DoDAF 2.0 Capability modeling (CV-1 drives the architecture) Project modeling

When to transition Capabilities are identified and have a funding source Service-oriented architecture environment Ongoing projects need alignment to provide a mission thread

that is supported by multiple systems or services

One important point to consider when transitioning to DoDAF 2.0 is that the underlying metamodel is not backward compatible with DoDAF 1.5. After an architecture is updated to 2.0, it is not easy to revert to 1.5.For the transition, for existing architectures, the easiest approach is to take the existing data (the AV-2) from DoDAF 1.5 and use it as a basis for models created in 2.0. Other reusable assets from 1.5 include the OV-3 and the SV-6.The service and system models are similar to 1.5, but need to be separated into their own views. The modeling for a service environment has been enhanced to include ports.Capabilities can be reused from 1.5, with the additional ability to model them. Projects and project modeling can be done as well, but did not exist in 1.5. The capability viewpoint now scopes and bounds the architecture, with the CV-1, Capability Vision being the driving model. In DoDAF 1.5 the driving model was the OV-1. While some organizations are looking to transition to 2.0 immediately, the added benefits of 2.0 will not be realized if the organization continues to model their information without taking into account the new philosophy of creating architectures that is expressed in DoDAF 2.0. The value of 2.0 relies on an enterprise view of the architecture that shows the relationships between capabilities, projects, services, and activities. This view is then filtered down to the capability/segment and component architectures. Without an overall enterprise view of the dependencies, the component architectures will continue to be developed in isolation.Transitioning should happen in these types of instances:

Capabilities are identified and are now used as a funding source: Justification for a project requires a direct link to a needed capability.

Service-oriented architecture environment: If you are transitioning to a service-oriented environment, DoDAF 2.0 can show not only which systems will be replaced by which services, but it also enables you to model, in the project view, the timeline for the transition to services and retirement of systems

Ongoing projects need alignment to provide a mission thread that is supported by multiple systems or services: If multiple projects are placed in a single funding category (this has been referred to as a system of systems) and need to interact to meet a mission thread (for example, to respond to domestic terrorist threats) DoDAF 2.0 provides a modeling capability that did not exist in 1.5 to show how different projects interact to meet a mission thread.




35


Course outlineModule 0: Course overviewModule 1: Overview of DoDAF 2.0Module 2: DoDAF 2.0 viewpointsModule 3: A brief overview of







36


DoDAF 2.0 modeling with IBM Rational SystemArchitect V11.4 Module 2 - DoDAF 2.0 Viewpoints



1


DoDAF 2.0 Modeling with IBM Rational System Architect V11.4Module 2: DoDAF 2.0 viewpoints

ContentsModule overview 2-2The eight viewpoints of DoDAF 2.0 2-4Overlay of DoDAF 1.5 and 2.0 2-5DoDAF 2.0 development path 2-6Physical Exchange Specification (PES) 2-8Mapping DoDAF 1.5 data elements to 2.0 2-9Diagram changes 2-12Overview of viewpoints and models 2-13




2


Module overview After you complete this module, you will be able to describe these items : Definitions for each of the eight viewpoints Path for model development Key models from the eight viewpoints Transition strategies for DoDAF 2.0 Physical Exchange Specification




3


Communicate: Fit-for-Purpose architecture descriptions

Image from http://cio-nii.defense.gov/sites/dodaf20/presentation.html

As you saw earlier, architectural information must be collected and presented in the correct scope and with a purpose and expected use, in a way that aids the decision-making process of the stakeholders at the different tiers.




4


The eight viewpoints of DoDAF 2.0

This graphic is from the DoDAF 2.0 Volume 2, Figure 3-1. It gives a brief description of the purpose of each view.All Viewpoint (AV): Captures the scope of the architecture and where the architecture fits in relation to other architectures. Another use of the All Viewpoint is for the registration of the architecture to support the net-centric goals of making Architectural Descriptions visible (discoverable by other architectures). The AV facilitates reuse across architectures and provides consistency in the metadata.Capability Viewpoint (CV): Describes capability taxonomy and evolution. The CV is used to answer the following questions:How does a particular capability or capabilities support the overall mission/vision? What outcomes are expected to be achieved by a particular capability or set of capabilities? What services are required to support a capability? What is the functional scope and organizational span of a capability or set of capabilities? What is the current set of capabilities that is being managed as part of a portfolio?Data and Information Viewpoint (DIV): Used to capture data, and there should be a tight integration between models. The Communities of Interest will use the DIV. Operational Viewpoint: Uses capabilities that are defined in the Capability Viewpoint and puts them in the context of an operation or scenario. It defines the functional scope of the capability or capabilities for which a department or project is responsible. Project Viewpoint: Improves support to the portfolio management process. The Project Models can be used to answer the following questions: What capabilities are delivered as part of this project? Are there other projects that either affect or are affected by this project? To which portfolios do the projects or projects belong? What are the important milestones that relate to this project? When can I expect the capabilities addressed by this project to be in place? Services Viewpoint: Shows the how of the Operational Viewpoints what. Services support war fighting and business functions (operational activities), as well as linking to capabilities. Services include internal system functions, HCI and GUI functions, or functions that consume or produce service data between services (for example, data transformation). External services are also considered. Standards Viewpoint: Defines standards at the enterprise level, and then applies them to each relevant solution. Standards include Doctrinal standards, Operational standards, Business standards, Technical standards, Industry standards, Industry implementation guidelines, Rules and criteria. The DoD Information Technology Standards and Profile Registry should be used to determine the minimum set of standards and guidelines for DoD systems. Systems Viewpoint: Has not changed since DoDAF 1.5, except that services have been removed.




5


1. AV-1: Overview and Summary Information2. AV-2: Integrated Dictionary3. CV-1: Vision4. CV-2: Capability Taxonomy5. CV-3: Capability Phasing6. CV-4: Capability Dependencies7. CV-5: Capability to Organizational Development Mapping8. CV-6: Capability to Operational Activities Mapping9. CV-7: Capability to Services Mapping10. DIV-1:Conceptual Data Model11. DIV-2: Logical Data Model12. DIV-3: Physical Data Model13. OV-1: High-Level Operational Concept Graphic14. OV-2: Operational Resource Flow Description15. OV-3: Operational Resource Flow Matrix16. OV-4: Organizational Relationships Chart17. OV-5a: Operational Activity Decomposition Tree18. OV-5b: Operational Activity Model19. OV-6a: Operational Rules Model20. OV-6b: State Transition Description21. OV-6c: Event-Trace Description22. PV-1: Project Portfolio Relationships23. PV-2: Project Timelines24. PV-3: Project to Capability Mapping25. SvcV-1 Services Context Description26. SvcV-2 Services Resource Flow Description27. SvcV-3a Systems-Services Matrix28. SvcV-3b Services-Services Matrix29. SvcV-4 Services Functionality Description 30. SvcV-5 Operational Activity to Services Traceability Matrix31. SvcV-6 Services Resource Flow Matrix32. Svc

introduccion a dodaf

Documents

nonibm product

nonibm web sites

local ibm representative

exchange of information

doublebyte dbcs information

products andor

equivalent product

license inquiries