DoDAF Maintenance Update (v2.03)

5 Jan 2012

DoDAF Team

22

Outline

• Recap of the DoDAF Configuration Management Process

• CM Plan (CMP)• ASRG, FAC, and DoDAF-DM2 WG• CM Processes Overview• CM “Business” Rules• Changes for 2.03• Formal coordination review plan

3

DoD Architecture Framework Evolution and CM

• C4ISR F/W’s– Joint Interoperability

• DoDAF 1.0– JCIDS, applicability beyond C4ISR

• DoDAF 1.5– Net-centricity and SoA

• DoDAF 2.0– Fit-for-Purpose, data-centric

architecture, improved models of systems, services, capabilities, rules, measures

• CM phase:– High-priority improvements, error

correction, emerging requirements– Stability for governance developers,

users, vendors

4

DoDAF is Under Formal CM

• Configuration Identification• Organizational roles,

responsibilities, and interactions• DoDAF-DM2 CM Processes

and Procedures • DoDAF-DM2 CM Business

Rules• Configuration Status Accounting

5

Configuration Identification

1. DoDAF Viewpoint Definitions. Conventions for the construction, interpretation and use of architecture views and associated architecture models.

2. DoDAF Model Specifications. Specifications from which architecture views representing an architecture are composed.

3. Glossary. Defines all non-demotic terms used in DoDAF and the DoDAF Meta Model.

4. DM2. Consists of a Conceptual Data Model (CDM) diagram and narrative description, a Logical Data Model (LDM) in an UML file adapted to IDEAS and a narrative description, and Physical Exchange Specification (PES) XML Schema Descriptions.

• NOTE that introductory, tutorial, document outlining, and web navigation documentation is considered under control of the DoDAF Journal editorial team and not subject to formal CM in scope of this plan.

66

CM Organizational Roles

CONFIGURATION STATUS

ACCOUNTING• CR Tracker (CRT)• CSAR• VDD

ASRG

ASRG Secretariat

FAC ITSC GIG CMB

DoDAF-DM2 WG

DARS WG

Ad Hoc WGs

ITSC Secretariat

ITSC WGs

IT Standards Principals

GIG Secretariat

EWSE IPTs

GTG Dev Groups

1. FAC Redirects on Specific CR2. DRAFT Baseline Comments3. DoDAF-DM2 Baseline Release

Approval

FAC

DoDAF-DM2 WG

FCM monthly report to FAC:1. WG Activity summary info brief2. Other info briefs of significant

recommendations being considered3. Configuration Status Accounting

Report (CSAR) document

77

CMP Processes

• CR Processing and Configuration Status Reporting

• Baseline Process

Change Request submitted via WG

web

Change Request communicated to WG CR Tracker

Enter into system as

“unassigned”

Record: “defer” and planned

version (if known)Reject

CoA and actionee(s)

Update status (defer, reject, in-progress) and, if necessary,

CoA and actionee(s)

Record as “done in v2.xx”

Prepare readahead:§ Next batch of

“unassigned”§ Topics selected at

last meeting§ Material submitted

by Actionee(s)§ FAC redirects

Conduct Meeting

Call for “unassigned” originators to brief

their CRs and facilitate discussions

Discuss problem and CoA: defer, reject, or select

CoA and actionee(s)

Present and prepared to

discuss

Yes

Move to bottom of queue

No

Facilitate CoA updates by actionee(s)Facilitate

topic discussions

Provide research findings, possible

solutions, etc.

More work

Minority member non-

concurr?

WG Business RulesData Dictionary

Current and working baselinesCR databaseDM2 models

Core process requriements

Report non-currence to

FAC

No

YesYes

Call for topics for

next meeting

Report to FAC:WG activity summary

CSARFAC redirect

impacts

Facilitate FAC redirect

CoA revisions

FAC vote to redirect?

Impact:Biz rulesProgramsVendors

Discuss new CoA and

actionee(s)

Yes

FA

CC

I &

CR

C

ust

odi

an

CR

Ori

gin

ator

s an

d

Act

ione

e(s

)F

CM

Yes

Bi-weekly

Monthly

See “Detailed CR Processing” for

amplification

CR WG review

C R r e q u e sts n e w vie w

C R r e q u e sts d e le te e xistin g vie w

N e w r e la tio n sh ip

Y e s

Y e s

Y e s

Y e s

Y e s

Y e s

Y e s

Y e s

C o n str u ct IA W vie w d e scr ip tio n style g u id e :

N a m e“ O n e -lin e r ”D e scr ip tio nC P U sa g e

D M 2 m a p p in g

S T A R T

E N D

C R r e q u e sts ch a n g e to e xistin g

vie wN o

N e w o r ch a n g e d te r m s

N o

A r tifa cts r e q u ir e d b y co r e p r o ce ss

g o ve r n a n ce

A r tifa cts in clu d e d in e xistin g vie w

S u b se t r e q u ir e d b y C P g o ve r n a n ce

R e q u e st d e le te a r tifa cts fr o m vie w

Y e s

Y e s

Y e s

P r o p o se C R a s R e je cte d

D e le te vie wN o tify C P

g o ve r n a n ce o f ch a n g e to o th e r

vie w

N o

D e le te a r tifa cts

fr o m vie wN o

A r tifa cts r e q u ir e db y co r e p r o ce ss

g o ve r n a n ce

A r tifa cts in clu d e din e xistin g vie w

S u b se t r e q u ir e d b y C P g o ve r n a n ce

N oN e w o r ch a n g e d

a r tifa cts

D D P r o ce ss

R e la tio n sh ip P r o ce ss

Y e s

N o

N o

C o n siste n cy , a lia s , o th e r Q A o r

vie w d e scr ip tio n style g u id e issu e s

P r o p o se C R a s D o n e

C R W G r e vie w

A ll a r tifa cts d e le te d ?

D e le te vie w

Y e s

P r o p o se C R a s R e je cte d

N o

N o

Y e s

N o

N o

N o

N o

N o

CR requests new term or definition change

CR requests DM2 relationship change

New relationship

Evaluate restitch impact : what

definitions and other rqmts effected

Can a supertype be determined

Determ ine supertype using BORO analysis

Should it be an alias ?

Collect source definitions and

enter in DD

Review and pick or formulate

definition

New or alias?

Enter mapped terms

Determ ine relationships in

DM2

Determ ine supertype using BORO analysis

Negative impact

Yes

NewAlias

No

No

Yes

AlternativesYes

No

Prpose CR as Rejected

Make change to DM2

Yes

NoAdd as alias to DD

Make change to DM2, add to DD,

and define

No

Yes

Yes

No

ST ART

END

END

DD Process

Relationship Process

CR WG review

Record:Date of WG

approval

Update status (defer, reject, in-progress) and, if necessary,

CoA and actionee(s) Restatus as “in progress”

for next version

Prepare for technical cutoff:

§ CR’s actionee(s) consider complete & ready for WG review

§ CR’s in progress§ FAC redirects

Conduct Technical Cutoff Meeting

Call for “done” actionee(s) to brief their CRs

Present solution and discuss

Majority present agree?

Yes

No

Call for “in progress”

actionee(s)

Provide status of solution(s)

Can make cutoff and / or priority for

version

Minority member non-

concurr?

Report non-currence to

FAC

NoYes

Yes

Report to FAC:§ CR’s “done”

for version§ CR’s

planned for version

§ Version release timeline & any issues

FAC vote to redirect?F

AC

CI &

CR

C

usto

dian

CR

Ori

gin

ator

s an

d

Act

ione

e(s

)F

CM

Yes Update date of status update

FAC vote to re-prioritize?

Yes

Technical cutoff & no FAC re-

prioritizations or redirects

No

Monthly

Bi-weekly

FAC vote to redirect?F

AC

CI &

CR

Cus

todi

an

CR

Origi

nat

ors

and

Act

ione

e(s

)FC

M

Conduct production of

draft for Component

review: document,

IDEAS model, XSD, VDD

Conduct QA: tech edit,

IDEAS tools , XML tools

Request entry of draft version into

SACP & tasker to

Components to review

Issue tasker for Component review

Collect Component comments

Re-status affected CR

Facilitate normal CR

processing of re-statused

CR’s

Report to FAC

Yes

All comments resolved & no FAC redirects

No

Conduct production of

final: document,

IDEAS model, XSD,

VDD

Conduct QA: tech

edit, IDEAS tools,

XML tools

Post to DoDAF

website & MDR;

deprecate prior version

Archive “dones”

Request promulgation

notice

Notify Components

of new version

Technical cutoff & no FAC re-

prioritizations or redirects

Yes

Yes

Monthly

88

CMP Business Rules

1. Terms and Definitions2. Aliases3. Core Process Requirement4. Aggregation Rule5. Subtype Rule6. Typed Relationships7. Attributes and Properties8. DoDAF Model Specification9. Information Pedigree10.Security Classification Marking

99

DoDAF-DM2 WG Status:Change Request Status

DM2 DoDAF Journal High Med LowOBE 2 2 0 0 0 0 2

Defer to 2.04 52 46 6 0 11 30 11In Progress for 2.03 40 22 17 1 0 21 19

Unassigned 99 57 37 5 4 55 40Consult IDEAS Group 20 18 2 0 7 8 5

Defer 92 87 5 0 41 23 28In Ver 2.03 43 39 3 1 0 3 40

Rejected 4 2 2 0 1 3 0In Progress for Journal 5 0 0 5 0 4 1

No Action Required 0 0 0 0 0 0 0

CI LOE

1010

Packaging for Formal CM

• Vol. I– DM2 Conceptual Model– DoDAF Viewpoints & Models

• Vol. II– DM2 Logical DM– DoDAF Model Specs– DoDAF Glossary– SparxEA .EAP DM2

• Vol. III– DM2 Physical DM: PES– SparxEA .EAP IDEAS Foundation

11

• TECHEDITS• Normative parts separated from informative parts

– Normative parts subject to formal coordination with DoD Components– Informative parts moved to DoDAF Journal

• Document + Webpages • Major DM2 CR’s:

– Rules and Desired Effects:1. Their Descriptions are produced by rule and goal-setting authorities2. They are consumed by Activities (ala Controls in IDEF0)3. Conforming Activities are subtypes

– Information resource flow was simplified into flatter type structure so it would be logically correct and consistent with other Resource Flows, e.g.,

• Aircraft 123 on my scope {all reports on A/C 123} {TADIL-J 3.2 msg}

– Capability made a subtype of Property so that it is the set of Tasks performed under Conditions that meet certain performance standards (Measures)

• Makes Capability comparison and dependencies more direct (simple set operations)– Distinguished that Guidance influences Activity from Rules that control Activity– Added SoA Joint Action concept– Continued work on distinguishing Roles (within scope of EA) from types of Persons

(outside scope of EA)

11

Changes for v2.03

exists spatio-temporally a set usable in, e.g., SV-6

1212

Marine Corps - Led TECHEDIT Team

• Marine Corps commented on many incorrect, ambiguous, and inconsistent statements– After working on this for several meetings, the WG

requested a rewrite rather than line-by-line fixes

• SPAWAR noted many undefined and inconsistent terms in the DoDAF model

• A long-standing CR asked for a DM2 diagram for each DoDAF model as in DoDAF 1.x documents

1313

TECHEDIT Team Rules

• Must follow DoDAF-DM2 WG rules (per CM Plan)

• Structure of each model specification:– Name. The twenty-four revised names agreed to by the WG

under CR #579 shall be used.

– One Sentence Description. The twenty-four revised “one-liners” agreed to by the WG under CR #579 shall be used.

– Narrative Description (one page maximum). DoDAF Glossary terms (in DM2 or aliases) shall be used per DoDAF-DM2 CM Business Rule #8.

– Meta-model diagram (one-half to one page).

– Other Names for this artifact (one-quarter page).

14

OV-2 As-Is

Text is lengthy…but doesn’t actually ever get around to unambiguously specifying content for an OV-2 model…

1515

TECHEDIT Example (pg 1 of 2)

SHALLS & MAYS

3.5.3 Organizations and Resources (OV-2)

a. Description. This model identifies and describes resources consumed and produced by activities performed by organizational-performers.

b. Narrative. This model emphasizes the exchange of resources among organizational performers, that is, performers capable of responsibility. These resources include information, materiel, and performers. The dependency between a resource to be consumed by one activity and a resource produced by another activity may be described as the flow of resources from producer to consumer. Activities are modeled in OV-2 models only in detail sufficient to show the relationships between resources produced by the activities of one organizational performer and the resources consumed by the activities of other organizational performers.

c. Activities are seen in OV-2 models much as they are in other DoDAF models. An activity consumes resources to produce resources. Performers in OV-2 models are resources who are capable of responsibility rather than resources that are materiel, systems, or services. Such performers—organizations and persons in roles—follow guidance, rules, and standards to carry out their activities. Performers carry out their activities under conditions that affect their performance.

d. Performers and other resources are related to their locations to ensure that resources to be consumed are available to activities when and where those resources are needed and that performers are there to carry out those activities when those resources are available.

e. Activities and resources may be measured. Guidance of various sorts may refer to types of applicable measures, and specific measures for specific activities may be drawn from such guidance.

f. Activities and resources shall be modeled. In particular, resources that are information shall be modeled. Types of organizations shall be modeled; specific organizations may be modeled. Persons in roles may be modeled. Types of locations of resources may be modeled, and specific locations may also be modeled. Rules and conditions may be modeled. Measures related to activities, resources, performers, locations, rules, and conditions may be modeled.

1616

TECHEDIT Example (pg 2 of 2)

g. Meta-model. Figure 3.5.3-1 shows the DoDAF meta-model for OV-2 models.

Figure 3.5.3-1: DoDAF meta-model diagram for OV-2 models

h. Alternate names: Operational Resource Flow Description; Organizational Resource Flows Identification.

i. Notes. (a) The architectural data of an OV-2 model may be grouped and ordered by organizational-performers who perform activities that produce resources. (b) The architectural data presented by an OV-2 artifact is typically a subset of the architectural data presented by an OV-3 artifact. Activities and measures may be de-emphasized by an OV-2 presentation.

class OV-2

Activity

Resource

Performer

activityConsumesResource

activityPerformedByPerformer

activityProd ucesResource

PersonRole

Individua lResource

Organiza tionType Organization

IndividualPerformer

PerformerCapableOfResponsibility

Information

resourceInL ocationTypeLocationType

ruleConstrainsActivityRule

ConditionactivityPerformab leUnderCondition

Measure

+ numericValue: stringmeasure OfType

Can apply to any of the core elements

Location

17

• Name: Systems Interface Description• One liner: The identification of systems, system items, and their interconnections.• Description:

– composition and interaction of Systems– links together the operational and systems architecture models -- a SV-1 may represent the realization of a requirement

specified in an OV-2 – there may be many alternative SV models that could realize the operational requirement. – in an “As-Is” architecture, the OV-2 may simply be a simplified, logical representation of the SV-1 to allow communication of

key Resource Flows to non-technical stakeholders. – A System Resource Flow is a simplified representation of a pathway or network pattern, – Note that Resource Flows between Systems may be further specified in detail in SV-2 Systems Resource Flow Description

and SV-6 Systems Resource Flow Matrix.– Sub-System assemblies– SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed– optionally overlay Operational Activities and Locations – In many cases, an operational activity and locations depicted in an OV-2 may well be the logical representation of the

resource that is shown in SV-1.– The SV-1 is used in two complementary ways:

• Describe the Resource Flows exchanged between resources in the architecture. • Describe a solution, or solution option, in terms of the components of capability and their physical integration on

platforms and other facilities. • Detailed Description:

– Systems and sub-systems – The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact with Systems. – Capability and Performers which is used to gather together systems, assets and people into a configuration, which can meet a

specific capability. – A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems,

performer and activities (functions) and their interactions. – SV-1 contributes to user understanding of the structural characteristics of the capability.– The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a system

cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both). – Organizational aspects can now be shown on SV-1 (e.g., who uses System). – Resource structures may be identified in SV-1 – DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a position relative to

a structural hierarchy. – Any System may combine hardware and software or these can be treated as separate (sub) Systems. DoDAF V2.0 includes

human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.

– optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2

SV-1 Issues Identified by DoDAF WG

• Every phrase analyzed contains problematic terms or expressions that are:– not defined

– used mysteriously

– inconsistent within this description or across the document

– ambiguous

– vague

– suggest content exists elsewhere that does not exist

– logically, operationally, or technically wrong

Spotlight on synopsis prepared by DoDAF WG. Highlighted words were found to be problematic.

18

SV-1 Content Guidance for Template and Descriptions

• Several distinct pieces are currently described. They should be refactored:1. SV-1a Interface Description. The SV-1a shows interfaces (Resource Flows)

between Systems, Services, and/or Person Types.

2. SV-1b Perfomer Configuration Diagram. Interface Description plus composition (whole-parts) of Resources involved. If Locations are involved in the configuration, relationships to Resources.

3. SV-1c Functional Allocation. Activities (System Functions) performed by Systems, Services, and Person Types.

4. SV-1d Organizational Resources. Shows Resources that are part of (whole-part) Organizations.

5. SV-1e Organizational Dependencies. Shows Organizations whose Activities are reified by System Functions (Activities) performed by Performer Configurations.

6. All views should show traceability to higher-order reifications, other views that constitute requirements, and/or other non-view requirements. This should be restated for just about every model.

7. Systems relationship to Capabilities – already in SV-5.

19

To-Be SV-1a

•Refocused to be a model of system interfaces

(SV-1a)

2020

DoDAF v2.03 Release Plan

Task Name

Start New Baseline

Process CR's for new baseline

Begin Technical Cutoff

Technical Cutoff Process

Technical Cutoff

DRAFT Baseline Production

DoD CIO Internal Review

DCIO Comments Adjudication

DRAFT Revision

DRAFT Baseline Entry in SACCP and Formal Review Taskerto Components

Component Review

Component Comments Adjudication

Revision and Production

ASRG Approve 2.03 Baseline

Publish and Promulgate New Baseline

Begin Processing CR's for Next Update (2.04)

9/1

10/20

11/17

9/24

9/24

Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep OctQtr 3, 2010 Qtr 4, 2010 Qtr 1, 2011 Qtr 2, 2011 Qtr 3, 2011 Qtr 4, 2011 Qtr 1, 2012 Qtr 2, 2012 Qtr 3, 2012 Qtr 4, 2012

21

Next: Systems Engineering and Architecture Harmonization and

Efficiency

SystemO & M

System Validation

System Verification

Subsystem Verification

Component Verification

Component Design

SystemDesign

Prototyping

MSA

CBAValidation &

Verification

Build

Acquisition Model Decisions & Milestones

CMMIProcess Areas

Requirements Development (RD)Requirements Management (REQMTechnical Solution (TS)Product Integration (PI)Verification (VER)Validation (VAL)

TEMPcapabilities

TEMPoperational

TEMPsystemStdV

AV

CV

DIV1OV

DIV2

DIV3

StdVDIV2

Unit Test

SwDD; IDD; DBDD

SvcVSV

SvcVSV

SwRS; IRS

SDD

RD

REQM

TS

VER

VAL

PI

MS-A

SRR

SFR

MS-B

CDR

TRR

SVR

MS-C

Typical Systems Engineering Work Products

• System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS)

• System Design Document (SDD) / System Segment Design Document (SSDD)

• Software Requirements Specification (SwRS)

• Software Design Document (SwDD)• Interface Requirements Specification

(IRS)• Interface Control Document (ICD) /

Interface Design Document (IDD)• Data Base Design Document (DBDD)• Test and Evaluation Master Plan (TEMP)

PDR

Technology Development (TD)

Engineering &Manufacturing Development (E&MD)

Capabilities Based Assessment (CBA)Material Solutions Analysis (MSA)

System Engineering Technical Reviews

System Requirements Reviews (SRR)System Functional Reviews (SFR)Preliminary Design Reviews (PDR)Critical Design Reviews (CDR)Test Readiness Review (TRR)System Verification Review (SVR)

DoDAF ViewpointsAll (AV)Capabilities (CV)Operational (OV)Data / Information (DIV)Systems (SV)Services (SvcV)Standards (StdV)

JCIDS DocumentsInitial Capabilities Doc (ICD)Capabilities Design Doc (CDD)Capabilities Production Doc (CPD)Information Support Plan (ISP)

SRD

CDDfinal; ISPfinal

CDDprelim; ISPprelim

CPD

ICD

Notional Systems Development “V”

2222

Questions?