Object Management Group (OMG) Unified Profile for DoDAF & MODAF (UPDM)

The Need for UPDM Motivation To significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling, promote architecture model reuse and maintainability, improve tool interoperability and communications [among] stakeholders, and reduce training impacts due to different tool implementations and semantics To improve integration between system of systems modeling & system modeling to support post acquisition life cycle design modeling Implements the Conceptual Models of DoDAF and other AFs Compatibility with Existing Tools Unified Modeling Language (UML 2.x) (UPDM Level 0) System Modeling Language (SysML 1.x) (UPDM Level 1) Support: UPDM fully supported by DoD, MOD, and International Defence Enterprise Architecture Specification (IDEAS) Working Group Statement and slides available on OMG website

Historical Development of Architectural Frameworks NAF* v1.0 NAF v3.0 Scope of “Unified Profile for DoDAF and MODAF” (UPDM)approved Dec 2008 MODAF Meta-Model (M3) expressed using UML Notation __________ * NAF = NATO AF 2005 2007 MODAF v1.0 MODAF v1.1 MODAF v1.2 C4ISR Architecture Framework v2.0 DoDAF 2005 2007 2008 1997 DoDAF v1.0 DoDAF v1.5 C4ISR Architecture Framework v1.0 2.0 (Late 2008) 2003 2007 1996 3

Cross References and Links DoD Metadata Registry (DMDR) DoD Architecture Registry (DARS) GIG Technical Guidance Links UPDM Group: http://www.updm.com/ DoD Position on Unified Profile for DoDAF & MoDAF (UPDM) OSD DISR UPDM UPDM RFC Brief to OMG C4I DTF 2008-09-23 UPDM Group Position Statement presented at the OMG UPDM Position Statement UKUS_Final DoD Enterprise Architecture Conference 2009, St Louis, MO; 1 – 4 June 2009: http://www.afei.org/brochure/9a05/index.cfm

Systems Architecture & Design Lecture 6 The Design Process Brian E. White, Ph.D. 25 May 2009 Version 2 (v2)

Functional and Logical Decomposition Outputs (1/2) System architecture model Defines the underlying structure and relationship of system elements (e.g., hardware, software, communications, operations, etc.) and basis for partitioning of requirements into lower levels to point that design work can be accomplished Usually results in DoDAF Operational View products

Systems Architecture & Design Lecture 7 Analysis of Alternatives Brian E. White, Ph.D. 1 June 2010 Version 3 (v3)

Example: Enterprise Architecture (EA) Repository Other EA Repositories EA Repository Business Architecture Standard Operating Procedure (SOP) Manuals Systems Architecture Technical Standards Profile Policies Business Process Data Base (DB) Systems Inventories Program /Earned Value Management (EVM) Tracking Network Mgmt System Mgmt DB Organization/ Staff Module Resource Request Matrix (RRM) DB Government Performance and Results Act (GPRA) Reporting Technical Standards Profile Performance Contract Others?

Architecture or Archeology? Both! Info Representations Documents & Reports Variety of Skills & Activities! Asset Analysis & Repository Design: Bringing Order to Chaos Key Decisions User Profiles Operational Processes Business Analyses Decision Data Analyses Network Modeling Information Relationships Assurance Model Design Systems Analyses Interface Application Inventories Access/Usage Analyses Connectivity Leverage Existing Artifacts: Content & Format Data Sharing & Integration System Inventories Pedigree Analyses Data Integrity Network Access & Availability Avoid “Creative Writing” Enterprise Information Repository Development Conceptual Information Model Logical DM Development DBMS Design Meta-data Modeling Meta-Model Development Physical DM Identification of Authoritative Information for Decision Support

Systems Architecture & Design Lecture 8 Decision Analysis Brian E. White, Ph.D. 8 June 2010 Version 3 (v3)

Systems Architecture & Design Lecture 9 Architectural Modeling, Architectural Description Languages, and Systems Architecting Challenges Brian E. White, Ph.D. 15 June 2010 Version 2 (V2)

What is Architectural Modeling? Architecture can be regarded as the set of principal design decisions made about a system We can define models and modeling in those terms An architectural model is an artifact that captures some or all of the design decisions that comprise a system’s architecture Architectural modeling is the reification* and documentation of those design decisions How we model is strongly influenced by the notations we choose An architectural modeling notation is a language or means of capturing design decisions Often called an Architecture Description Language (ADL) There will be more about ADLs in the next section _________ * That which makes something abstract more concrete or real

How Do We Choose What to Model? Architects and other stakeholders must make critical decisions What architectural decisions and concepts should be modeled? At what level of detail? With how much rigor or formality? These are cost/benefit decisions The benefit of creating and maintaining an architectural model should significantly exceed the cost

IEEE 1471 Architecture Description Standard Stakeholder System Viewpoint Concern View Model Architecture Library 1 1..* Conforms to Described by Defines Method Has Covers What do you think of this diagram?

IEEE 1471 in Words A system has 1 architecture An architecture is described by 1 or more architecture descriptions An architecture description is composed of 1 or more of stakeholders, concerns, viewpoints, views, and models A stakeholder has 1 or more concerns A concern has 1 or more stakeholders A viewpoint covers 1 or more concerns and stakeholders A view conforms to 1 viewpoint A viewpoint defines the method of a model A view has 1 or more models and a model is part of 1 or more views A viewpoint library is composed of viewpoints

Survey of Modeling Approaches Generic approaches Natural language PowerPoint-style modeling UML/SysML Early architecture description languages Darwin Domain- and style-specific languages Koala Architecture Analysis and Design Language (AADL) Extensible architecture description languages Acme Architecture Description and Markup Language (ADML) xADL What does extensible mean here?

Early Architecture Description Languages ADLs proliferated in the 1990s and explored ways to model different aspects of software architecture Many emerged from academia Focus on structure Components Connectors Interfaces Configurations Focus on formal analysis None used actively in practice today Tool support has waned Ideas influenced many later systems though

Darwin General purpose language with graphical and textual visualizations focused on structural modeling of systems Advantages Simple, straightforward mechanism for modeling structural dependencies Interesting way to specify repeated elements through programmatic constructs Can be modeled in -calculus for formal analysis Mathematical formalisms for describing and analyzing properties of concurrent computation Does not contain primitives such as numbers, Booleans, data structures, variables, functions, or even the usual flow control statements (such as if... then...else, while...) Can specify hierarchical (i.e., composite) structures Disadvantages Limited usefulness beyond simple structural modeling No notion of explicit connectors

Koala Darwin-inspired notation for specifying product lines of embedded consumer-electronics devices Advantages Advanced product-line features let you specify many systems in a single model Direct mapping to implemented systems promotes design and code reuse Disadvantages Limited to structural specification with additional focus on interfaces

AADL In November 2004, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named the Architecture Analysis & Design Language (AADL) AADL is a modeling language that supports early and repeated analyses of a system’s architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics The language employs formal modeling concepts for the description and analysis of application system architectures in terms of distinct components and their interactions

AADL (Continued) It includes abstractions of software, computational hardware, and system components for Specifying and analyzing real-time embedded and high dependability systems, complex systems of systems, and specialized performance capability systems Mapping of software onto computational hardware elements AADL is especially effective for model-based analysis and specification of complex real-time embedded systems

AADL (Concluded) Advantages Disadvantages Allows detailed specification of both hardware and software aspects of a system Automated analysis tools check interesting end-to-end properties of system Disadvantages Verbose Large amount of detail required to capture even simple systems Emerging tool support and UML profile support

ArchiMate The Open Group's open and independent modeling language for enterprise architecture For describing, analyzing and visualizing the relationships among business domains in an unambiguous way A common language for describing the construction and operation of business processes, organizational structures, information flows, IT systems, and technical infrastructure See http://www.archimate.org/

Architecture and Strategy Strategic decisions are technical Technical decisions are strategic Consider the loop Strategic Identity is “We take end-to-end responsibility.” Dominant error types are hard to find, except in the field Drives toward designs that provide good diagnostics, easy fixes Enables strategy of “We take end-to-end responsibility.” Another alignment (or failure to) Do you know the tradeoff of revenue vs. cost for getting it right versus getting it sooner? How do discovery costs and recovery costs compare? Is your technical architecture supportive of the tradeoff? Do you know how to adapt to the tradeoff in your business or organization? What company might this remind you of?!

Architecture and Strategic Identity What is this system? At the simplest level, architecting is about bringing problem and solution into alignment It’s about finding satisfactory and feasible solutions to ill-structured problems At another level, architecting is about aligning tensions between problem, solution, program, and organization Program: How we go about implementing a solution? Organization: The human grouping that does the solving The “Art” of Systems Architecting has, at least, two components The art of synthesis of creative solutions The art of balance in multiple, disparate dimensions of problem, organization, and program

Three Systems Paradigms A&E Architecting and Engineering Ill-structured problem: A problem where the statement of the problem depends on the statement of the solution Adapted from: Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000