DoD Architecture Framework 2.0 A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures

303 Pages·2015·33.2 MB·English

by  Dr. Steven H Dam

DoD Architecture Framework 2.0 – A Guide to Applying System Engineering to Develop
Integrated, Executable Architectures
Published by SPEC Innovations
10440 Balls Foard Road, Suite 230
Manassas, VA 20109
www.specinnovations.com
Copyright © 2014 SPEC Innovations, Manassas, VA All rights reserved.
Trademarks
All terms mentioned in this book that are known to be trademarks or service marks have
been appropriately
Warning and Disclaimer
is implied. The information provided is on an “as is” basis. The author and publisher shall
have neither liability nor responsibility to any person or entity with respect to any loss or
damages arising from the information contained in this book.
ISBN-13: 978-1502757623 ISBN-10: 1502757621
DoD Architecture Framework Publication Date: February, 2015 Printed in the United
States of America
About the Author
Steven H. Dam, Ph.D., ESEP is the President and Founder of Systems and Proposal
Engineering Company
(SPEC Innovations), and a DoDAF training instructor. He has been involved with
research, experiments, operations analysis, software development, systems engineering
and training for more than 40 years.
Dr. Dam participated in the development of C4ISR Architecture Framework and DoD
Architecture Framework (DoDAF), Defense Airborne Reconnaissance
and Net-Centric Enterprise Services (NCES) architecture.
He currently is applying systems engineering techniques to various DoD,
DOE and commercial projects. Dr. Dam has a B.S. in physics from George Mason
University and a Ph.D. in physics from the University of South Carolina.
He is a long-time member of INCOSE and a past president of the San Diego Chapter and
the Washington Metropolitan Area Chapter (WMA). He is currently the Programs Chair
for the WMA Chapter. Dr. Dam presents various papers and seminars to the WMA
Chapter and received an Expert Systems Engineering Profes
About SPEC Innovations
Systems and Proposal Engineering Company (SPEC Innovations) was established in 1993.
Their services include systems engineering services and training, proposal engineering
management and training, software development, and DoDAF training and expertise.
SPEC Innovations, continues to stay in the forefront of emerging technologies. Most
recently, SPEC Innovations had the privilege of participating in the initial drafting of the
new open standard Lifecycle Modeling Language (LML).
They have supported the International Council on Systems Engineering (INCOSE)
Washington Metropolitan Area (WMA) chapter in various roles, including President,
Programs Chair, and Communications Chair, helping transform the WMA Chapter from a
small group meeting monthly to a dynamic webcasting venue that has quadrupled its reach
to the systems engineering community.
SPEC Innovations has contributed to other systems engineering organizations, to include
the American Institute of Aeronautics and Astronautics (AIAA) and National Defense
Industrial Association (NDIA). Their conferences, thus adding to the growth and
knowledge of the systems engineering community.
Acknowledgements
I would like to thank my editors, Elizabeth Steiner and Sarah Campbell for all their help in
trying to keep this poor physicist’s grammar correct.
Special thanks to US Navy Captain Warren Vaneman, Ph.D. for his review and comments.
Thanks also belong to the men and women who have come to our DoDAF training courses
and contributed their thoughts and ideas along the way.
I also want to express my appreciation to the dedicated OSD, MITRE and contractor
personnel who devel
to the body of knowledge in architecture and systems engineering without which any book
like this would be impossible to write.
Last, but not least, I want to thank my wife, Cindy, for her patience and support.
Instructional Tool: Innoslate
In Part 2: Practical Application, Innoslate, a systems engineering tool, is used to
demonstrate developing integrated, executable architectures. Follow along with the
Innoslate tool to increase not only your knowledge, but your skills in DoDAF.
Create an Innoslate account today. Sign up by going to innoslate.com. If you are a student,
sign up with your student email address for a Free Academic Plan. Otherwise, sign up for
the Free Starter Plan.
Instructions:
1. Go to innoslate.com.
2. Click Sign Up Free.
3. Enter your student or professional email
address.*
4.
inbox.
5. -
tions.**
6. In no time you will have a Free Academic
Plan or a Free Starter Plan.
7. Use the Innoslate tool during Part Two:
Practical Application.
*Student email addresses will automatically
receive the Free Academic Plan.
within 1 hour, please contact us.
Need help or have a question?
Contact us at 571-485-7800 or email us at [email protected] and we would be glad
to assist you.
Table of Contents
PartOne:Theory ix
Preface: Do We Still Need a DOD Architecture Framework? xi
Chapter 1: What is the DoDAF Anyway? 1
1.1 What is Architecture? 5
1.2 What is DoD Architecture Framework? 9
Chapter 2: What are the DoDAF Models? 23
2.1 How Should We Select the Models? 32
2.2 How Can We Tailor the Models? 34
2.3 How are the DoDAF Models Related to One Another? 36
Chapter 3: What is the DoDAF Missing? 41
3.1 Systems Engineering Methodologies for Architectures 43
3.2 Why isn’t SE Always Popular? 46
3.3 How Do We Determine the Appropriate Mix of Technique, Process, and Tool(s)? 50
Chapter 4: What Techniques Make a “Good” Methodology? 55
4.1 What is Structured Analysis? 55
4.2 What are Object-Oriented Techniques? 58
4.3 What is Model-Based Systems Engineering? 60
4.4 How Do We Develop Executable Architectures and Designs? 65
4.5 How Do We Select a Technique? 70
Chapter 5: What Tools Make a “Good” Methodology 73
5.1 What Tools are Available? 73
5.2 Tool Interoperability 75
5.3 DM2, UPDM, and PES in More Detail 77
5.4 How Do We Select the Right Tools? 82
Chapter 6: What Processes Make a “Good” Methodology? 85
6.1 What Lifecycle Model Should We Use? 85
6.2 What Processes Work? 87
6.3 How Do You Start? 92
6.4 How Can We Develop Detailed Architecture? 94
6.5 What Else Do You Need? 99
Part Two: Practical Application 101
Chapter 7: Problem Description 103
Chapter 8: Project Planning 107
8.1 Creating the Project Plan 107
8.2 Creating the Project Viewpoint Models 110
8.3 The AV-2: Your Knowledgebase 114
Chapter 9: Phase 1: Gathering Artifacts and “Requirements” 117
9.1 Step 1: Capture and Analyze Related Documents 117
9.2 Step 2: Identify Assumptions 121
9.3 Step 3: Identify Existing/Planned Systems 121
9.4 Step 4: Capture Constraints 122
Chapter 10: Phase 2: Developing the Concept of Operation s 125
10.1 Key DoDAF Models 125
10.2 Step 5: Develop the Operational Context Diagram 140
10.3 Step 6: Develop Operational Scenarios 143
10.4 Step 7: Derive Behavior 146
11.1 Key DoDAF Models 149
11.2 Step 8: Derive Assets 164
11.3 Step 9: Allocated Actions to Assets 165
11.4 Step 10: Prepare Interface Diagrams 165
Chapter 12: Phase 4: Verifying the Design 169
12.2 Step 12: Perform Dynamic Analysis 171 12.3 Step 13: Develop Operational
Demonstration Master Plan 173
Chapter 13: Phase 5: Documenting and Communicating the Architecture
177
13.1 Step 14: Provide Options 177
Chapter 14: How is the DoDAF Being Implemented? 187
14.1 The DoD Decision Support System Framework 191
14.2. Joint Capabilities Integration and Development System (JCIDS) 193
14.3. DoD’s Requirements for Interoperability: CJCSI 6212.01F 195
14.4 How Will Architectures be Evaluated? 198
PREFACE
Do We Still Need a DoD Architecture
Framework?
In This Chapter
A Brief History of the DoDAF
The Importance of the DoDAF in the Past The Current Need for the DoDAF
The Relevance of DoD Architecture Framework Today
In the late 1980’s, the problems with large architectures and systems became apparent.
The interoperability among systems was so bad that soldiers had to use pay phones and
other electronic devices from home to communicate with the Pentagon.1
2;
- posed a variety of architectural solutions. Unfortunately, these solutions came in many
forms and formats.
- ed or supported each other. They needed a framework to determine the appropriate
information content that would help distinguish between the architectures. To accomplish
this, as in most Government programs, they created a working group, which in this case
was named the Architecture Working Group (AWG). The AWG was comprised of
representatives from every command, service, and agency across the Department of
Defense. Although they were intended to represent their particular organizations, these
representatives brought their own perspectives on what was architecture. This approach is
a common problem with working groups, but a necessary one to make progress.
htm, accessed July 2010.
weapons/scud.html, assessed August 2010.
x Part One: Theory
The product of this working group was C4ISR Architecture Framework 1.0 (refer to The
Evolution of the Architecture Framework3). It was a new standard. It provided a way for
architecture developers to compare their architectures and determine which was best. It
was called C4ISR (command, control, communications, computers, intelligence,
surveillance, and reconnaissance) because it was in this domain that interoperability was a
major problem. It was not a standard, because DoD had recently (circa 1993) removed the
requirement for the
and not a mandatory standard.