1. Architecture Ignore at your own risk (DODAF 2
Architecture Ignore at your own risk (DODAF 2.0 – It’s the law for all future DOD programs)
Dale Waldo Boeing Associate Technical Fellow - Systems Engineering
Lou Pape Boeing Associate Technical Fellow - Systems Engineering

2. Outline
What is System Architecture
DoDAF V2.0
6/23/2010 2

3. What is Systems Architecture
6/23/2010 3

4. Systems Architecture Wikipedia
A system architecture or systems architecture is the conceptual design that defines the structure and/or behavior of a system.
An architecture description is a formal description of a system, organized in a way that supports reasoning about the structural properties of the system. It defines the system components or building blocks...and provides a plan from which component products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage...investment in a way that meets business needs
6/23/2010 4

5. Table 1: Four Architecting Methodologies
Systems Architecture
Architecting: the art and science of designing and building systems
Table 1: Four Architecting Methodologies
Normative (solution-based)
Examples: building codes and communications standards
Rational (method based)
Example: systems analysis and engineering
Participative (stakeholder based)
Examples: concurrent engineering and brainstorming
Heuristic (lessons learned)
Examples: Simplify, Simplify, Simplify… and Scope
Maier & Rechtin- “The Art of Systems Architecting”
6/23/2010 5

6. Systems Architecture
A system is a collection of different things that together produce results unachievable by themselves alone. The value added by systems is in the interrelationships of their elements
Architecting is creating and building structures, i.e., “structuring.” Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests
Architecting is both an art and a science -- synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the customer, and particular concern with certification standards and readiness for use
Maier & Rechtin- “The Art of Systems Architecting”
6/23/2010 6

7. DoDAF Definition
DoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries It doesn’t tell you how to architect, it tells you how to title and organize your system’s descriptive artifacts
6/23/2010 7

8. What is Good Architecture
A good architecture meets the needs of the stakeholders (especially the users) to their satisfaction, does not violate principles of system architecture, and takes into account the relevant -ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires
Really good architectures are also elegant (intellectually clean of unnecessary complexities or 'exceptions'), can direct a builder to cost-effective structures that can be completed within a reasonable time frame, conceptually pleasing to all stakeholders (especially the user), and provide some special advantage (such as a competitive advantage) or utility to the customer
6/23/2010 8

9. Some Powerful Systems Engineering Heuristics
All designs are valid if they deliver the performance within the constraints
System Level Architecture optimizes the specialist disciplines, and constrains them
Systems need to be built to tolerate change and expansion beyond current stakeholder needs
System Stakeholders are one more than you know about; and known stakeholders have at least one more need than you know about now
You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term, over current systems
Don’t ever try to build it all at once – evolve the system based on highest value early, and rapid learning about realities
Manage the details through focus on high-level measurable objectives, not through bureaucracy
6/23/2010 9

10. All Design Processes Should Involve Iteration
All design processes can and should involve iteration
Many systems are too complex, and many architects are not competent enough, to do a perfect job on the first pass
Many data points only become available later in the architecture or design process
Therefore, every architecture design process should involve iteration; the process should be designed to be conducted over and over again until a satisfactory solution is reached
6/23/2010 10

11. The Customer is the Judge of Quality
An architecture that satisfies the architect but not the customer is useless
The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture
While the architect may attempt to educate the customer to their mutual benefit, in cases of difference of opinion it is the customer's opinion that matters
6/23/2010 11

12. KISS (Keep It Simple,Stupid)
The architect should strive to adhere to the KISS principle, "keep it simple, stupid."
The system architecture should be as simple as possible without conflicting with other design principles
Architectures that are more complex than necessary will result in sub-optimal systems
This principle is also known as Occam's Razor
6/23/2010 12

13. Modeling as a Architectural Tool
The “systems” we deal with are increasingly complex, as is the environment they operate in
Difficult to comprehend, understand, predict, control, interface with, explain, etc.
Larger, more complex tasks
Increasingly “Systems of Systems”
Modeling allows fuller, cheaper exploration of the design space (within limitations)
Object Mgmt Group (OMG) and INCOSE are Driving Toward Model Driven Development (MDD)/Model Driven Architecture (MDA)
UML 2.0, SysML
6/23/2010 13

14. Intro to DoDAF V2. 0 Overview: http://cio-nii. defense
Intro to DoDAF V2.0 Overview: Slides:
6/23/2010 14

15. DOD Acquisition Landscape has Changed
The DOD is:
No longer telling the contractor the solution they have chosen
Now seeking to leverage the expertise of the contractor
Seeking to have a choice of the best options available against which they will write the Systems Requirements Document (SRD)
Stating their goals for the product in a Statement of Objectives (SOO)
Asking the contractor to tell them what it really takes to achieve that SOO
6/23/2010 15

16. VERSION 15
3/27/ :52
Value of DoDAF V2.0
DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development in a way that will aid DoD managers
Fit-for-Purpose describes an architecture that is appropriately focused and directly supports customer needs or improves the overall process undergoing change. The models provide choices, based upon the decision-maker needs
Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA) - related techniques and tools
Adheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition Guide
Can be used in conjunction with Lean, Six Sigma and other Process Improvement methods
Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers
I didn’t know what you meant by this one
Adoption of DoDAF V2.0 benefits the decision-maker by organizing architecture information but allows the architect the freedom of presenting the data in his own format as long as it answers the questions that need to be addressed
6/23/2010 16

17. DoD Architecture Framework (DoDAF V2
DoD Architecture Framework (DoDAF V2.0) Original DoDAF Views have been expanded to better organize information and reflect data that practitioners actually use
Modified Viewpoints
The original DoDAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practice
All the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV)
The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc)
Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standards
The All Viewpoint (AV) is essentially the same
6/23/2010 17

18. DoD Architecture Framework (DoDAF V2.0)
New Viewpoints
Capability Viewpoint (CV) focuses on Capability data in support of Capability development and to standardize the capture of capability data
Project Viewpoint (PV) focuses on the Portfolio Management/Cost Performance information to explicitly tie architecture data to project efforts (what used to be called status charts)
A major new thrust of V2.0 is the term “fit for purpose”
The individual artifacts are intended to be “fit for their purpose” of documenting, managing, and guiding the system development – not generated specially and uniquely for a high level review
6/23/2010

19. DoDAF V2.0 DoDAF Metamodel (DM2) DoDAF V1.5 6/23/2010 Data &
Information
Viewpoint
OV-7
Services
SV-11
All “Service”
Versions of
SV Products
Systems
All “Systems”
DoDAF V1.5
Capability
Project
Standards
Operational
Rest of OVs
All TVs
All
All AVs
DoDAF V2.0
New
Updated
Moved
DoDAF Metamodel (DM2)
Fit For
Purpose
Presentation
Dashboards
Graphical
Depictions
Reference
Models
Fusion
Products
Composite
DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions.
In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.).
Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience.
DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues.
BUILD ONE:
The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose
The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations
All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views.
BUILD TWO:
The new Systems view better accommodates our legacy system descriptions.
The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services.
The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.
The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective.
BUILD THREE:
The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both.
Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View.
There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker.
6/23/2010

20. Perspectives: Viewpoints That Fit-the-Purpose
Renamed
New
New
New
Overarching aspects of architecture context that relate to all models
All Viewpoint
Articulate the data relationships and alignment structures in the architecture content
Data and Information Viewpoint
Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts
Standards Viewpoint
Systems Viewpoint
Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions
Services Viewpoint
Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions
Operational Viewpoint
Articulate operational scenarios, processes, activities & requirements
Capability Viewpoint
Articulate the capability requirement, delivery timing, and deployed capability
Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process.
Project Viewpoint
New
DoDAF organizes the DoDAF-described Models into the following viewpoints:
The All Viewpoint describes the overarching aspects of architecture context that relate to all viewpoints.
The Capability Viewpoint articulates the capability requirements, the delivery timing, and the deployed capability.
The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.
The Operational Viewpoint includes the operational scenarios, activities, and requirements that support capabilities.
The Project Viewpoint describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. An example is the Vcharts in Chapter 4 of the Defense Acquisition Guide.
The Services Viewpoint is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.
The Standards Viewpoint articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.
The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.
Architecture viewpoints are composed of data that has been organized to facilitate understanding.
6/23/2010 20

21. DoDAF V2.0 Focus: Terms DoDAF V1.5 DoDAF V2.0 Architecture
Alignment with ISO and 15407
DoDAF V1.5
DoDAF V2.0
Architecture
Architectural Description
Architecture data
Architectural data
Product
Model (a template for collecting data)
View (a model with data for an architecture)
View
Viewpoint
Models are templates for organizing and displaying data in DoDAF 2.0
Previous versions of DoDAF referred to these as ‘Products’
An example of a Model is an OV-2, OV-5, SV-1, CV-5
Views are the result of collecting and populating Models with data and then presenting it
Views are a Model populated with specific data
Viewpoints are a collection of models/views
Previous versions of DoDAF just referred to these as ‘Views’
Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability Viewpoint (CV)
The collection of information, specifically Views and/or Viewpoints, used to document the architecture is referred to as an Architectural Description
Previous versions of DoDAF referred to these as just an ‘Architecture’
A few words about terminology before we go very far. There is a lot of terminology in the presentation, and you will be faced with it each time you discuss an architecture. In addition, there are changes from previous versions of DoDAF that you might be familiar with, and normally use.
In our part of the engineering world, everything starts will identifying a need, developing a plan for action, and collecting information about whatever it is that seems to need update or other types of change.
Unfortunately, data or information is not easy to read or even pretty to look at. For that reason, people create presentations, such as this, to explain what they mean, seek further information, do analysis, and eventually gain concurrence.
To do those things, we in the community look for ways to explain what we mean. Generally, for technical things, we use models—templates that look the way we usually express ourselves. When we ‘fill in’ the data, we have a view of the data. We used to call a view a ‘product’. A collection of these views is called a viewpoint, and becomes the architectural description.
The difference is that you don’t have to use the examples contained in DoDAF—they are NOT required. You can create your own if you wish from the data collected. These are called User-created Views or Fit-for-Purpose Views. If you are comfortable with the older DoDAF ‘products’, then you can use the DoDAF-described Views—all of the old products are listed among the DoDAF-described products.
DoDAF does describe a number of new views, as you will soon see. There is a lot of new material in DoDAF 2.0
6/23/2010

22. Methodology: DoDAF V2.0 Six-Step Architecture Development Process
Determine the
intended use of
the architecture 1
Determine
scope of
architecture 2
Determine data
required to
support
development 3
Collect, organize,
correlate, and
store architecture
data 4
Conduct
analyses in
support of
objectives 5
Document
Results IAW
Decision-Maker
needs 6
Provide list of data
needed and use
cases
3.1
Model to
DM2 Concept
List
Review list of
architecture data
and determine if
it meets the use
3.2
DM2 Conceptual
Data Model &
Logical Data Model
Assist with the
Architect’s
data collection
processes
4.1
List of
Potential
Collection
Methods
Selected
Verify the data
collected meets
the use cases
5.1
Example
Uses
Fit-for-Purpose
Use
Determine how
data needs to be
presented
6.1
Legacy
Products
User
Requirements
Presentations
Detailed
Steps for
Decision-
Maker
It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience.
If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts.
There are six steps is the DoDAF methodology:
1-Determine the intended use of the architecture
2- Determine the scope of the architecture
3- Determine data required to support architecture development
4- Collect, organize, correlate and store data
5- Conduct analysis in support of architecture objectives
6- Document results
Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed.
With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.
6/23/2010

23. OV -1 is: OV -2 is: Graphical in nature
An easy way to understand what is trying to be explained by the architecture as a whole
Provides an excellent summary of the architecture when combined with AV-1
A mission and highlighted primary operational nodes
OV -2 is:
Graphical in nature
One of the work products required for an integrated architecture
A way to track the need to exchange information from specific Operational Nodes (that play a key role in the architecture) to other Nodes
6/23/2010 23

24. GIG Tactical Theater Communications Infrastructure (OV-1 Example)
Wideband Networking Waveform Capability Central to Tactical GIG
Broadband LOS
Radio Access
Point
Broadband LOS
Radio Access
Point
6/23/2010 24

25. Operational Node Connectivity Description OV-2 Example
6/23/2010 25

26. The Development Process for Operational Views
6/23/2010 26

27. A (Not Exactly) Fortuitous Coming Together of UML & DoDAF…
OV-1
High-Level Operational Concept Graphic
HLOC
High-Level Operational Concept Graphic (not really UML; more .ppt)
OV-2
Operational Node Connectivity Description
NCD
Node Connectivity Description
OV-3
Operational Information Exchange Matrix
SOS
System Operational Sequence
OV-4
Organizational Relationships Chart
NRD
Node Relationship Diagram
OV-5
Operational Activity Model
UCD
Use Case Diagram or Activity Diagram
OV-6a
Operational Rules Model
UCS
Use Case Specification (Text)
OV-6b
Operational State Transition Description
StCD
State Chart Diagram
OV-6c
Operational Event-Trace Description
OTS
Operational Trace Sequences
OV-7
Logical Data Model
(Related to AV-2, Dictionary)
CRD, LDM
Class Relationship Diagram, Logical Data Model
6/23/2010 27

28. Systems Engineering Process
Systems Engineering Management and Analysis
Plans/Schedules
Requirements Management
Risk Management
SEIT Coordination
Subcontractor Management
Closed Loop Corrective Action
TPMs
Customer Requirements
SRR
Requirements Analysis
Mission Requirements
Requirements Trades
Requirements Capture
SDR
Optimized System Design
Functional Analysis/ Allocation
Functional Analysis
Functional Trade Studies
Requirements Flowdown
System Synthesis
Design Trade Studies
Specialty Engineering Integration
CAIV
Subsystem Requirements Flowdown
Legacy Program Information
System Definition
Detailed
Design
System Verification & Evaluation
Prototype
I&T
Design Reviews
System
Integration
System Test
Validated System
6/23/2010 28

29. Systems Engineering Process
Architecture holds it all together
Systems Engineering Management and Analysis
Plans/Schedules
Requirements Management
Risk Management
SEIT Coordination
Subcontractor Management
Closed Loop Corrective Action
TPMs
Customer Requirements
SRR
Requirements Analysis
Mission Requirements
Requirements Trades
Requirements Capture
SDR
Optimized System Design
Functional Analysis/ Allocation
Functional Analysis
Functional Trade Studies
Requirements Flowdown
System Synthesis
Design Trade Studies
Specialty Engineering Integration
CAIV
Subsystem Requirements Flowdown
Legacy Program Information
System Definition
Detailed
Design
System Verification & Evaluation
Prototype
I&T
Design Reviews
System
Integration
System Test
Validated System
6/23/2010 29

30. System Architecture Selection Process Steps
Down Select Was Based Upon Critical Measures,
their Weighting,
and the selected Figure
of Merit (FOM)
Requirements
Analysis
(S&C SEPM 1.2)
Functional Analysis
System Synthesis
(S&C SEPM 1.3)
Down Select Was Based Upon
All Measures,
their Weighting, and the selected Figure
Determine Which
Measures Should Be
Used In the Selection Process
Establish Weights For
Each Measure
Architecture-1
Architecture-2
Architecture-(N)
Concept-1A
Concept-1B
Concept-1N
Concept-2A
Concept-2B
Concept-2N
Testability
Risk
Maintainability
LCC
Non-
Recurring
Cost
Schedule
Competitive
Discriminators
Customer
Bias
Producibility
System A
System B
System (M)
“Best Value”
System Concept
System Analysis
and Control
(S&C SEPM 1.4)
Functional
Performance
Cost Estimate
(DTUPC)
Concept-NN
Concept-NA
Perform
Sensitivity
System Architecture
Development Process
Verification Loop
Document the
Process
Risk Analysis of
Final System
Concept
Modify concepts to
combine the best
features of each
Legacy
Components
Transform
Architectures
(Functional to
Physical)
Define Alternative
System Concepts
Define Physical
Interfaces
Grade Each Concept For The Selected
Critical Measures
Select
Preferred
Product and
Solutions
Grade Each Candidate
Concept for All Measures
Concept-NB
Design Loop
1. Emphasizing the process of mapping the system functional architecture into a number of physical elements that comprise the architecture candidates.
2. The insertion of legacy subsystems into the candidate physical architectures is done here. The use of legacy subsystems or elements can require a repartition of the functional architecture if the grouped functions assigned to that object cannot all be accomplished by the legacy item.
3. The architecture alternatives evaluation is accomplished by performing a trade study using an executable model of the architecture. The executable model is a integration of the static and dynamic models used to define the architecture and a computer simulation engine.
6/23/2010

31. "YOU ARE THE STEWARD OF THE WHOLE, NOT THE OWNER OF THE PART. ” Dr
"YOU ARE THE STEWARD OF THE WHOLE, NOT THE OWNER OF THE PART.” Dr. John Pickering
6/23/2010 31