Architecture Framework Standardization

Architecture Framework Standardization

Fatma Dandashi, Ph.D.

[email protected]

Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task Force

May, 2005

3

What is DODAF

• The Department of Defense (DoD) Architecture Framework (DODAF)– Defines a common approach for modeling, presenting, and

comparing a System-of-Systems (SoS) architecture (Systems View) along with associated standards (Technical View) within the context of the mission capabilities (Operational View).

• The principal objective of the Framework is to – Ensure that architecture models can be compared and related

across organizational boundaries, including Joint and multi-national boundaries

4

What is MODAF*

• UK Ministry of Defence Architectural Framework– Based on DODAF with some minor changes to TV-1, OV-1, OV-

2, SV-1 and SV-2 – Adds two new viewpoints:

• Strategic Capability Views – these views define the high level capability vision, the capabilities and sub-capabilities (capability functions) required to support that vision, the dependencies between capabilities, the phasing in and out of systems to support the capabilities, and the organizations in which those systems are to be deployed.

• Acquisition Views – these views define the project team structures required to deliver network enabled capabilities. They also define the inter-project dependencies and specify the lines of development status at significant project milestones.

Source: http://www.modaf.com/

5

System-of-Systems Characteristics

Boundaries

Interactions

The increased use of architectures, as a basis for making programmatic decisions, raises the bar for their level of consistency, precision and scalability

SoSs needed to achieve a single capability typically:

•Are not usually managed or funded under a singular authority

•Composed from complex systems that provide independent functionality

•Are hard to bound•Are distributed over time and space

6

Why an Architecture FrameworkMilitary

Capabilities

-Expressed as Concepts-Modeled via: Ways (Behavior /ops activities) and Means (ops resources)

SoS and System Components

Expressed as • System Components• Functions• Interfaces

7

Requires Collaboration of many Communities or Stakeholders

Architecture data can be a means for integrating stakeholder processes, thereby improving communications, analyses, and tradeoff decisions!

TestersTesters

Developers/Developers/IntegratorsIntegrators

VendorsVendors

RegulatorsRegulators

CustomersCustomers

Project Project ManagersManagers

8

Problem Statement

• DODAF V1.0 Volume II provides guidance on using UML– Used extensively to represent DODAF architecture products

across industry– Not sufficiently precise resulting in multiple interpretations (no

one-to-one mapping between UML diagrams and DODAF products)

– Based on UML 1.x which has been superseded by UML 2

DODAF UML guidance is inadequate to facilitate communications, architecture product reuse and

maintainability, and tool interoperability

9

Solution Statement

• DODAF V 1.0 exposed a need for architecture-based model-driven systems engineering

• SysML is a UML profile for model-driven systems engineering

• Initial analysis indicates good coverage of all DODAF/MODAF views with SysML*

Develop a UML Profile for DODAF/MODAF that provides an industry standard SysML representation of DODAF/MODAF

architecture views

* see Bailey et al in references section

10

Why Standards ?

• Standards can offer

– Broader acceptance

– Improved integration with other frameworks

– Improved tool interoperability

– Reduced training requirements

11

Systems Engineering Standards & Architecture Frameworks

SADTSADT

ProcessStandards

Modeling & SimulationStandards

Modeling Methods

ZachmanDODAFArchitecture Frameworks

OOSEM

UML/SysMLUML/SysML IDEF0

Interchange Standards

MOF/XMIMOF/XMI STEP/AP-233 CADM

OtherHLA

Modeling Simulation

ToolToolSupportSupport

EIA 632 CMMI *ISO 15288 IEEE 1220

ADMRUP SE

OtherRM-ODP

Other

The slide illustrates just one of the many standard-based tool chains that can be defined!

CADMCADMMOF/XMIMOF/XMI STEP/AP-233STEP/AP-233

DODAFDODAF

UML/SysMLUML/SysML

TOGAF

12

Vision –Standards-based Tool Interoperability

SV4

AP233

OMG SysMLOther SE Views

Operational

Syst

ems

Technical

DODAF

AP2xx

Detailed Design,Manufacturing,Life Cycle Support,…

ISO 10303STEP APs

specifies requirements for

AP233

ArchRepository

XMI

AP

233

13

What is SysML?

• A UML Profile For Systems Engineering in response to the requirements developed by the OMG, INCOSE, and AP233

• Supports the specification, analysis, design, verification and validation of a broad range of complex systems that may include hardware, software, data, personnel, procedures, and facilities

• Represents a subset of UML 2 with the extensions to meet the requirements for systems engineering– enhancements to composite structure and activity diagrams – two new diagram types for requirements and parametric– allocation relationships and auxiliary constructs– SysML alignment with ISO AP-233

14

Example DODAF ProductsUsing a UML Extension

• Example was provided by Artisan Software• Artifacts included here are for exposition purposes only

• There are several other vendor implementations of DODAF using SysML (e.g., Telelogic, I-Logix) – There are similarities and differences among the tool

implementations– The various implementations expose the need for

standardization

15

Typical OV-2 Using Artisan Tool*

«OperationalNode»Mission Planning

Logistics

Routing

Assessment

Coordination

HQ

Artillery Command

Air Command

C-Rout : Route Info«InformationExchange»

C-Log : Munitions Status«InformationExchange»

ASS-C(W) : Weapons Intel«InformationExchange»

ASS-C(F) : Flight Intel«InformationExchange»

Log-Art : Mission Plan«InformationExchange»

Route-AC : Mission Plan«InformationExchange»

C-HQ : Mission Intel«InformationExchange»

ArtC-Ass : Weapons Intel«InformationExchange»

AC-Ass : Flight Intel«InformationExchange»

OV-2 : Structure for Mission Planning

* Courtesy of Artisan Software

Item Flow

Op Node

Organization

16

Typical OV-5 Using Artisan Tool

Mission Planning

Coordination

Prepare Route

«op activity»

Nominate Artillery Units

«op activity»

Prepare Mission Intell Report

«op activity»

Logistics

Verify and Instruct Artillery Units

«op activity»

Routing

Produce Detailed Routing

«op activity»

Gather Attack Intelligence

«op activity»

Assessment

Gather Flight Intelligence

«op activity»

«InformationExchange»«InformationExchange»

C-Rout«InformationExchange»«InformationExchange»

C-Log


ASS-C(W)


ASS-C(F)

OV-5 : Mission Planning Flow


Op Node

Information Exchange

17

Typical SV-1 Using Artisan Tool

«systemNode»Aircraft

: Class1

«systemNode»MissilePlatform

: Class1

«systemNode»Mobile HQ

: Class1

«systemNode»Main HQ

: Class1

MHQ-HQ : Intell Data

HQ-MHQ : Mission Data«interface»

HQ-AC : Flight Data«SystemDataExchange»

AC-HQ : Intell Data«SystemDataExchange»

«interface»

MHQ-MP : Target Data«SystemDataExchange»

MP-MHQ : Intell Data«SystemDataExchange»

«interface»

DeployedSystems

Defence PlanningWeapon CoordinatorCartography

DeployedSystems

WeaponReconnaisanceSupportedOpNodes

IntelligenceWeapons Control

DeployedSystems

Flight ControlNavigationReconnaisance

DeployedSystems

Flight AssessmentFlight CommsMission PlanningMission Assessment

SV-1 : Systems Interaction Overview


Item Flow

Systems Node

18

Typical SV-1 Detail Using Artisan Tool

«systemNode»MissilePlatform

«system»: Weapon

«system»: Targetting

«system»: Guidance

«system»: Reconnaissance

«systemNode»Mobile HQ

: Cartography«system»

: Weapon Coordinator«system»

: Defence Planning

«systemNode»Main HQ

«system»: Mission Planning

«system»: Mission Assessment

«system»: Flight Planning

«system»: Flight Assessment

«systemNode»: Aircraft

«system»: Flight Control

«system»: Navigation

«system»: Reconnaissance«interface»

DP-WC : Defence Plan

WC-W(T) : Target Data

«interface»«interface»Recon Intell

MP-DP : Mission Data

SV-1 : System Interaction Detail


System Node

System

Interface/ Item Flow

Interface

19

IssueRFP

VoteAdoption of a SpecificationRFPRFP

4-6 mo InitialSubmissions

InitialSubmissions

6-8 mo RevisedSubmission(s)

RevisedSubmission(s)

8-10 mo

EvaluateSubmissions

EvaluateSubmission

ToolsTools

Need

ImplementationImplementation12 mo

LOI

OMG Technology Adoption Process (Typical)

We are here

20

UML Profile for DODAF/MODAF RFPScope

• Use DODAF V1.0 as a baseline• Incorporate MODAF’s additional views (Acquisition and

Strategic)• Incorporate additional requirements from DODAF V2.0

WG (e.g., support for overlays) • Support for modeling system-of-systems architectures

– Systems that include hardware, software, data, personnel, procedures, and facilities (DOTMLPF & MOD Lines of Development )

– Service oriented architectures and net-centricity

21

UML Profile for DODAF/MODAF RFPRequirements Summary

• Develop RFP that specifies the requirements for a UML Profile for DODAF/MODAF – Standard Notation (concrete syntax)– Implementation-independent domain meta-model (abstract

syntax and constraints)– Views and Viewpoints– Architecture Products– Extensible library of reusable architecture elements and patterns– Standard data interchange mechanism (e.g., XMI)

• Optional requirements to support:– Standard diagram interchange mechanism– Other architecture frameworks (e.g., NATO’s Framework, ..)

22

UML Profile for DODAF/MODAF Roadmap

Feb 2008Feb 2007Feb 2006

SysML/AP233 Alignment

Feb 2005

DODAFV 1.0(2004)

DODAFV 2.0

SysMLV 1.0

Adopted

OMG Kickoff(Feb 05)

RFP(Nov 05)

UML Profile for DODAF/MODAF

SysMLV 0.9

DODAF V 2.0Inputs

MODAFV 1.0

23

Summary of Interested Parties*

• Tool Vendors:– Artisan

– Borland

– I-Logix

– Popkin Software

– Proforma Corp

– Telelogic

• Other Support:– OSD, MOD, others

– BAE Systems

– Boeing

– Eurostep

– LMC

– Raytheon

– Sandia Labs

– Thales

– Unisys

* partial list

24

Long Term Solution

• Develop standard for the specification of general architecture frameworks– Leverage IEEE 1471– Make applicable to a broad range of architecture frameworks

• Military and commercial e.g., Zachman Framework

– Utilize experience from UML Profile for DODAF/MODAF standardization to reduce risks

– Issue RFI followed by RFP through OMG

Questions?

28

Industry Feedback

• Presented architecture framework standardization effort through the OMG in early February

• Resistance to immediate standardization of a UML profile for a generic Architecture Framework– Scope is too large to complete in a reasonable amount of time– Tool Vendors concerned about lack of market and technical risks

• Strong request for a UML profile that implements standard representations for DODAF

• Support for follow-on effort to establish standards for the specification of generalized architecture frameworks

Documents

Architecture Framework Standardization