1 / 25

Architecture Framework Standardization

Architecture Framework Standardization. Fatma Dandashi, Ph.D. dandashi@mitre.org Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task Force May, 2005. What is DODAF. The Department of Defense (DoD) Architecture Framework (DODAF)

kiley
Download Presentation

Architecture Framework Standardization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture Framework Standardization Fatma Dandashi, Ph.D. dandashi@mitre.org Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task Force May, 2005

  2. 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

  3. 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/

  4. 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

  5. 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

  6. Developers/ Integrators Customers Project Managers Vendors Regulators Testers Requires Collaboration of many Communities or Stakeholders Architecture data can be a means for integrating stakeholder processes, thereby improving communications, analyses, and tradeoff decisions!

  7. 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

  8. 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

  9. Why Standards ? • Standards can offer • Broader acceptance • Improved integration with other frameworks • Improved tool interoperability • Reduced training requirements

  10. UML/SysML STEP/AP-233 MOF/XMI Systems Engineering Standards & Architecture Frameworks Process Standards EIA 632 ISO 15288 IEEE 1220 CMMI * Architecture Frameworks DODAF RM-ODP TOGAF Other DODAF Zachman Modeling Methods Other RUP SE ADM OOSEM SADT Modeling & Simulation Standards Other HLA Tool Support IDEF0 UML/SysML Modeling Simulation Interchange Standards CADM STEP/AP-233 CADM MOF/XMI The slide illustrates just one of the many standard-based tool chains that can be defined!

  11. Systems Technical Operational AP233 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

  12. 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

  13. 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

  14. Typical OV-2 Using Artisan Tool* Op Node Organization Item Flow * Courtesy of Artisan Software

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

  16. Typical SV-1 Using Artisan Tool Item Flow Systems Node * Courtesy of Artisan Software

  17. 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

  18. EvaluateSubmission LOI Need Vote Adoption of a Specification IssueRFP EvaluateSubmissions 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

  19. 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

  20. 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, ..)

  21. 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 0.9 SysMLV 1.0 Adopted SysML/AP233 Alignment Feb 2005 Feb 2006 Feb 2007 Feb 2008

  22. 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 Summary of Interested Parties* * partial list

  23. 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

  24. Questions?

  25. 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

More Related