Architecture Framework Standardization Fatma Dandashi, Ph.D. 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:

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 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! Testers Developers/Integrators Vendors Regulators Customers ProjectManagers

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 SADT Process Standards Modeling & Simulation Standards Modeling Methods ZachmanDODAF Architecture Frameworks OOSEM UML/SysML IDEF0 Interchange Standards MOF/XMI STEP/AP-233 CADM Other HLA ModelingSimulation ToolSupport EIA 632 CMMI * ISO 15288IEEE 1220 ADMRUP SE Other RM-ODP Other The slide illustrates just one of the many standard-based tool chains that can be defined! CADM MOF/XMI STEP/AP-233 DODAF UML/SysML TOGAF

12 Vision – Standards-based Tool Interoperability SV4 AP233 OMG SysML Other SE Views Operational System s Technical DODAF AP2xx Detailed Design, Manufacturing, Life Cycle Support, … ISO STEP APs specifies requirements for AP233 Arch Repository XMI AP233

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 Products Using 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* * Courtesy of Artisan Software Item Flow Op Node Organization

16 Typical OV-5 Using Artisan Tool OV-5 : Mission Planning Flow * Courtesy of Artisan Software Op Node Information Exchange

17 Typical SV-1 Using Artisan Tool * Courtesy of Artisan Software 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» Recon Intell MP-DP : Mission Data SV-1 : System Interaction Detail * Courtesy of Artisan Software System Node System Interface/ Item Flow Interface

19 Issue RFP Vote Adoption of a Specification RFP 4-6 mo Initial Submissions 6-8 mo Revised Submission(s) 8-10 mo Evaluate Submissions Evaluate Submission Tools Need Implementation 12 mo LOI OMG Technology Adoption Process (Typical) We are here

20 UML Profile for DODAF/MODAF RFP Scope 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 RFP Requirements 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 DODAF V 1.0 (2004) DODAF V 2.0 SysML V 1.0 Adopted OMG Kickoff (Feb 05) RFP (Nov 05) UML Profile for DODAF/MODAF SysML V 0.9 DODAF V 2.0 Inputs MODAF V 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?

26 References 1.AP233 part of the STEP Standard (ISO10303), 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 CADM, All-DoD Core Architecture Data Model (CADM), 4.Cantor, Murray, “Rational Unified Process for Systems Engineering (RUP SE) -- Requirements Analysis and Design,” Rational Edge, October DeMarco, T., Structured Analysis and Systems Specification, Prentice Hall, (SADT) 6.EIA 632, “Processes for Engineering a System,” Electronics Industries Alliance (EIA) Standard, January, FIPS183, “Integration Definition for Function Modeling (IDEF0),” NIST, Dec. 1993, 8.Friedenthal, S., Kobryn, C. "Extending UML to Support a Systems Modeling Language," Proceedings of the INCOSE 2004 International Symposium, June, IEEE 1220, “Standard for Application and Management of the Systems Engineering Process,” IEEE, IEEE 1471, “Recommended Practice for Architectural Description of Software-Intensive Systems,” IEEE, IEEE (HLA), "Recommended Practice for High Level Architecture (HLA) Federation Development and Execution Process (FEDEP), IEEE, Sept ISO :2004, “Industrial Automation Systems And Integration -- Product Data Representation And Exchange,” Ed. 2, TC 184/SC 4 13.ISO/IEC 10746, “Information Technology—Open Distributed Processing -- Reference Model,” ISO/IEC, ISO/IEC 15288, “Systems Engineering—System Life Cycle Processes,” ISO/IEC, October ISO 15704, “Industrial Automation Systems—Requirements for Enterprise-Reference Architectures and Methodologies,” ISO, Lykins, Friedenthal, Meilich, “Adapting UML for an Object Oriented Systems Engineering Method (OOSEM) “, 15 January 2001, FIPS183, “Integration Definition for Function Modeling (IDEF0),” NIST, Dec. 1993, 18.OMG Document ad/ , “Systems Modeling Language Draft Specification V0.9,” OMG, January, OMG Document ptc/ Meta Object Facility (MOF) V 2.0 Core, OMG, Oct OMG Document -- formal/ , XML Metadata Interchange (XMI), v2.0), OMG, May OpenGroup, “Introduction to the Architecture Development Method (ADM),” doc/arch/p2/p2_intro.htmhttp:// doc/arch/p2/p2_intro.htm 22.OpenGroup, “The Open Group Architectural Framework (TOGAF),” 23.SEI, Capability Maturity Model Integration (CMMI) V 1.02b, Software Engineering Institute (SEI) of Carnegie Mellon University, December Zachman, John, “The Zachman Framework for Enterprise Architecture,”

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 Mellon’s 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 Engineering— System 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 Framework’s 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