Architecture Framework Standardization

1
Architecture Framework Standardization

• Fatma Dandashi, Ph.D.
• dandashi_at_mitre.org
• Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task
  Force
• May, 2005

2
Outline

• What are DODAF, MODAF
• Why an Architecture Framework
• Problem Statement
• Solution Statement
• Why Standards
• UML Profile For Systems Engineering (SysML)
• OMG Technology Adoption Process
• UML Profile for DODAF/MODAF
• Scope
• Requirements Summary
• UML Profile for DODAF/MODAF Roadmap
• Long Term Solution

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

• 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

Interactions
Boundaries
The increased use of architectures, as a basis
for making programmatic decisions, raises the bar
for their level of consistency, precision and
scalability
6
Why an Architecture Framework
Military 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!
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
Process Standards
EIA 632
CMMI
ISO 15288
IEEE 1220
Architecture Frameworks
DODAF
Other
RM-ODP
TOGAF
Zachman
DODAF
Modeling Methods
Other
ADM
RUP SE
OOSEM
SADT
Modeling Simulation Standards
Other
HLA
Tool Support
UML/SysML
IDEF0
Modeling
Simulation
Interchange Standards
STEP/AP-233
CADM
CADM
MOF/XMI
The slide illustrates just one of the many
standard-based tool chains that can be defined!
12
Vision Standards-based Tool Interoperability
ISO 10303 STEP APs
DODAF
specifies requirements for
Detailed Design, Manufacturing, Life Cycle
Support,
Other SE Views
OMG SysML
SV4
AP2xx
AP233
AP233
XMI
Arch Repository
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
Op Node
Organization
Item Flow
Courtesy of Artisan Software
16
Typical OV-5 Using Artisan Tool
Op Node
OV-5 Mission Planning Flow
Information Exchange
Courtesy of Artisan Software
17
Typical SV-1 Using Artisan Tool
Item Flow
Systems Node
Courtesy of Artisan Software
18
Typical SV-1 Detail Using Artisan Tool
System Node
SV-1 System Interaction Detail
systemNode
Main HQ
System
systemNode
Aircraft
systemNode
system
system
MissilePlatform
Flight Planning
Mission Planning
system
Flight Control
system
Weapon
system
system
Mission Assessment
Flight Assessment
system
Guidance
system
Navigation
interface
interface
Recon Intell
system
systemNode
Targetting
Mobile HQ
WC-W(T) Target Data
MP-DP Mission Data
system
Reconnaissance
interface
system
system
Cartography
system
Defence Planning
Weapon Coordinator
Reconnaissance
DP-WC Defence Plan
Interface/ Item Flow
Interface
Courtesy of Artisan Software
19
OMG Technology Adoption Process (Typical)
We are here
RFP
InitialSubmissions
4-6 mo
RevisedSubmission(s)
6-8 mo
Tools
Implementation
8-10 mo
12 mo
20
UML Profile for DODAF/MODAF RFPScope

• Use DODAF V1.0 as a baseline
• Incorporate MODAFs 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., NATOs
  Framework, ..)

22
UML Profile for DODAF/MODAF Roadmap
DODAFV 1.0 (2004)
DODAFV 2.0
DODAF V 2.0Inputs
MODAFV 1.0
UML Profile for DODAF/MODAF
RFP (Nov 05)
OMG Kickoff (Feb 05)
SysMLV 1.0 Adopted
SysMLV 0.9
SysML/AP233 Alignment
Feb 2005
Feb 2008
Feb 2007
Feb 2006
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

25
Questions?
26
References

1. AP233 part of the STEP Standard (ISO10303),
   http//ap233.eurostep.com
2. Bailey, I., Dandashi, F., Ang, H., Hardy, D.
   Using Systems Engineering Standards in an
   Architecture Framework, INCOSE Insight Magazine,
   Vol. 7, Issue 2, July 2004
3. CADM, All-DoD Core Architecture Data Model
   (CADM), https//pais.osd.mil/EnterpriseArchitectur
   es
4. Cantor, Murray, Rational Unified Process for
   Systems Engineering (RUP SE) -- Requirements
   Analysis and Design, Rational Edge, October 2003
5. DeMarco, T., Structured Analysis and Systems
   Specification, Prentice Hall, 1978. (SADT)
6. EIA 632, Processes for Engineering a System,
   Electronics Industries Alliance (EIA) Standard,
   January, 1999
7. FIPS183, Integration Definition for Function
   Modeling (IDEF0), NIST, Dec. 1993,
   www.itl.nist.gov/fipspubs/idef02.doc
8. Friedenthal, S., Kobryn, C. "Extending UML to
   Support a Systems Modeling Language," Proceedings
   of the INCOSE 2004 International Symposium, June,
   2004
9. IEEE 1220, Standard for Application and
   Management of the Systems Engineering Process,
   IEEE, 1998
10. IEEE 1471, Recommended Practice for
    Architectural Description of Software-Intensive
    Systems, IEEE, 2000
11. IEEE 1516.3 (HLA), "Recommended Practice for High
    Level Architecture (HLA) Federation Development
    and Execution Process (FEDEP), IEEE, Sept. 2000
12. ISO 10303-112004, Industrial Automation Systems
    And Integration -- Product Data Representation
    And Exchange, Ed. 2, TC 184/SC 4
13. ISO/IEC 10746, Information TechnologyOpen
    Distributed Processing -- Reference Model,
    ISO/IEC,1998
14. ISO/IEC 15288, Systems EngineeringSystem Life
    Cycle Processes, ISO/IEC, October 2002
15. ISO 15704, Industrial Automation
    SystemsRequirements for Enterprise-Reference
    Architectures and Methodologies, ISO, 2000
16. Lykins, Friedenthal, Meilich, Adapting UML for
    an Object Oriented Systems Engineering Method
    (OOSEM) , 15 January 2001, http//www.incose.org/
    chesapek/meetings/Adapting_UML_for_an_OOSEM.doc
17. FIPS183, Integration Definition for Function
    Modeling (IDEF0), NIST, Dec. 1993,
    www.itl.nist.gov/fipspubs/idef02.doc
18. OMG Document ad/05-01-03, Systems Modeling
    Language Draft Specification V0.9, OMG, January,
    2005
19. OMG Document ptc/03-10-04 Meta Object Facility
    (MOF) V 2.0 Core, OMG, Oct. 2003

27
Acronyms

• ADM The OpenGroup Architecture Driven
  Methodology
• ADTF Analysis and Design Task Force
• AP 233 Application Protocol 233
• C4I DTF C4I Domain Task Force
• CADM Core Architecture Data Model
• CMMI Capability Maturity Model Integration
  (Carnegie Mellons SEI)
• DODAF DoD Architecture Framework
• EIA 632 Electronics Industries Alliance
  Standard Processes for Engineering a System
• HLA High-Level Architecture
• IEEE Institute of Electrical Electronic
  Engineers
• INCOSE International Council On Systems
  Engineering
• ISO/IEC 15288 Systems EngineeringSystem Life
  Cycle Processes
• LOI Letter of Intent

• MDSD WG Model Driven System Design Working Group
• MODAF Ministry of Defence Architecture Framework
• MOF Meta-Object Facility (MOF), version 1.4
• OMG Object Management Group
• OOSEM Object-Oriented Systems Engineering Method
• RFI Request for Information
• RFP Request for Proposal
• RUP SE Rational Unified Process for Systems
  Engineering
• SADT Structured Analysis and Design Technique
• SEI Software Engineering Institute
• SoS System Of Systems
• SysML Systems Modeling Language
• TOGAF The Open Group Architectural Frameworks
• UML Unified Modeling Language
• XMI XML Metadata Interchange

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