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

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

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

4. Cross References and Links
DoD Metadata Registry (DMDR)
DoD Architecture Registry (DARS)
GIG Technical Guidance
Links
UPDM Group:
DoD Position on Unified Profile for DoDAF & MoDAF (UPDM) OSD DISR UPDM UPDM RFC Brief to OMG C4I DTF
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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24. 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?!

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

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