1. Enterprise Architecture as a Mission Enabler
2011 NASA PM Challenge
Long Beach, California
Josh Arceneaux
Booz Allen Hamilton
0

2. Contents
 What is Enterprise Architecture
 Why do Enterprise Architecture
 Is Enterprise Architecture Right for you?
 Getting Started in Enterprise Architecture
 Case Study: NASA Constellation Program
 Summary
1

3. What is Enterprise Architecture?
 According to Webster's Dictionary:
• Architecture: the art or science of building
• Enterprise: a unit of economic organization or activity
 Joining these two definitions we can surmise that Enterprise Architecture, at it’s most basic
definition, is:
The art or science of building a unit of economic organization or activity
 For purpose of this presentation, the “unit of economic organization or activity” is generically
any NASA program or Project
2

4. Why do Enterprise Architecture?
 COMPLEXITY
• If you can't describe it, you can't create it (whatever "it" is)
 CHANGE
• If you don't retain the descriptive representations after you create them (or if you never
created them in the first place) and you need to change the resultant implementation, you
have only three options:
– Change the instance and see what happens (High risk!)
– Recreate ("reverse engineer") the architectural representations from the existing (“As-
is") implementation. (Takes time and costs money!)
– Scrap the whole thing and start over again
*© 2007 John A. Zachman, Zachman International
3

5. Managing Complexity and Change in NASA
Programs
 Just how complex are NASA programs?
– That depends on the program, but generally they are just as, if not more complex than the
majority of commercial industry programs and projects
– Add to that the risks imposed by the environments that NASA missions operate in and one
could make the case that NASA programs and projects have ZERO room for error
 How often do NASA programs change?
– Daily, there is a reason the engineering, operations, and change control boards at NASA are
busy
– If you look at the engineering and operations level you could say that change occurs
constantly throughout the day
• After all isn’t that what smart folks do, create, invent, innovate, and drive change on a
constant basis
4

6. NASA Programs at a Glance
Programs
NPR’s Program Produce
Guide Manager
Project SE SW
Controls Manager Manager
What is missing
NPR 7123.1
NPR 7120.5D
Program Management
Systems Engineering
NPR 7150.2A
Software Engineering
?
5

7. The Program Structure: i.e. The Enterprise!
Without
Enterprise Architecture
With
Enterprise Architecture
Where do you want to drive?
6

8. Building the Enterprise
 Enterprise architecture and the principles behind enterprise architecture can complement
traditional program management, systems engineering, and software engineering practices to
enable a program to perform at closer to optimal efficiency.
 A key enterprise architecture principle involves taking a holistic approach to defining and
managing the program or project that allows the program participants and stakeholders to
attain and maintain situational awareness for both tactical decision making and strategic
planning
– You know what you have today,
– You know what you can expect to have tomorrow
– Therefore you can make well informed decisions that optimize today's needs and enable
you to meet tomorrow’s demands
7

9. What is contained in the Enterprise Architecture
• Business Processes and activities
USE
Business
• Data that must be
collected, organized, safeguarded,
Data USING and distributed
• Application such as custom or off-
the-shelf
Application RUN ON
• Technology such as computer
systems, networks, data centers
Technology
8

10. Is Enterprise Architecture Right for You?
 If we arrange our Enterprise
(Program/Project) into
different drivers and levels,
several “families” of
questions that may provide
valuable insight into your
program or project are then
answerable through
exercising an Enterprise
Architecture approach
 If as a program/project
manager these things are
important to you then, YES,
Enterprise Architecture is
right for you.
9

11. How much Enterprise Architecture do you Need?
Short Answer
 Short answer: As much or as little as is needed to define and effectively manage the program
or project
– Typically the larger the program/project and the more participants, more enterprise
architecture information is needed
– Additionally, the more detail and precision you require, the more enterprise architecture is
needed
…. do not use this!
When this is all you need….
10

12. How much Enterprise Architecture do you Need?
Longer Answer
 People: Who makes up the program/project (internal and external), how are they organized, what are their
roles and responsibilities, and how to the relate to one another
– An organization chart and accompanying RACI (or similar concept) can provide a wealth of knowledge
 Processes: What are the business processes and information that the program executers to produce their
products
– NPR 7123.a is the highest level business process for Systems Engineering within NASA
 Technology: What systems, applications, information, IT infrastructure does the enterprise utilize to facilitate
execution of the business processes
– Programs utilize program unique technology, center provided technology ,and agency provided
technology; What is the best usage of this technology?
 Controls: What is the governance model and how is it used to manage the enterprise
– What decisions are made by whom, under what circumstances, and by what mechanisms; Typically
NASA Boards and Panels
 Strategy: How is the enterprise going to evolve to meet the needs of tomorrow
– NASA development programs have defined lifecycles that determine the evolutionary path of the vehicles,
no such mechanism provides this for how the program/project will evolve as the economic, political and
technological environment changes.
11

13. How is the Enterprise Architecture Managed:
Frameworks
 The framework provides
guidance on what artifacts
are necessary to capture
information about the
enterprise and provides a
mechanism to identify and
visualize the relationships
between the enterprise
information
 There are many
frameworks, the majority of
which are some derivation
of the Zachman framework
12

14. 13
Federal Enterprise Architecture
Framework (FEA)
Department of Defense Architecture
Framework (DoDAF)
Project Viewpoint
Project Viewpoint
Describes the relationships between operational and capability
requirements and the various projects being implemented;
Details dependencies between capability management and the
Details dependencies between capability management and the
Additional Frameworks
Defense Acquisition System process.
Defense Acquisition System process.
systems, their composition, interconnectivity,
and context providing for, or supporting, DoD
Articulate the legacy systems or independent
Articulate the performers, activities, services,
Articulate the capability requirement, delivery
Articulate operational scenarios, processes,
and their exchanges providing for, or
timing, and deployed capability
Operational Viewpoint
Capability Viewpoint
supporting, DoD functions
Systems Viewpoint
Services Viewpoint
activities & requirements
functions
Standards Viewpoint
Standards Viewpoint
Articulate applicable Operational, Business, Technical, and
Industry policy, standards, guidance, constraints, and
Industry policy, standards, guidance, constraints, and
forecasts
Data and Information Viewpoint
Articulate the data relationships and alignment structures in
Articulate the data relationships and alignment structures in
the architecture content
All Viewpoint
Overarching aspects of architecture context that relate to all
Overarching aspects of architecture context that relate to all
models

15. Getting Started: What do you want to know?
 If you know the right questions to ask, you can model your enterprise effectively
Step 1
Determine the
Intended Use of the
Architecture
Step 2 Step 3 Step 4 Step 5 Step 6
Determine Scope of Determine Data Collect, Organize, C Conduct Analyses in Present Results IAW
Architecture Required to Support orrelate, and Store Support of Decision Maker
Architecture Architecture Data Architecture Needs
Development Objectives
14

16. How to get Started: Example
 Question: Are my business processes being executed effectively without overlap?
– Ineffective execution can cause, among others, schedule delays, excessive rework, lost or missing
information, unclear line of communication and authority
– Overlap can cause, among others, lack of authoritative data leading to ill or uninformed decision,
excessive cost, sub-optimal resource allocation.
Assumption: We are looking at the top level
business process, as defined in the NPR’s,
however this approach may be used to any level of
detail
Remember: Finishing Hammer or Powered Jack
hammer?
 For this exercise we will use the DoDAF 2.0 framework.
– Primary Models : Activity Model, Operational Rules Model, Event Trace Model
– Supporting Models: Conceptual Data Model, System Model, Organizational Model
– Will also need to define performance metrics
15

17. An Enterprise Architecture will not provide you
benefit unless
 It addresses real business problems and identified plausible solutions
 It provides key insight in an easily understandable fashion to a decision-maker
 It captures how the enterprise worked or didn’t and how it could be improved
 It illustrates how a change fit an enterprise and how it enabled improvement
 It was links with all other decision analysis processes including economic analysis
 It provides a clear order for change that was actionable and measurable
 It was develops in a rapid manner with input from key business or operations owners
16

18. Program/Project Management Process Overview:
NPR 7120.5D
17

19. Systems Engineering Process:
NPR 7123.1A
NO comparable
Process Diagram for
NPR 7150.2A
18

20. The Program/Project Lifecycle: Where it all comes
together
19

21. How the Models Work together
Organization Model Integrated Activity Model Operational Rules Model
Program PM Program /
Manager Model Project CCB
Executes Governed By
SECB SWCB
Project SE SW SW
Controls Manager Manager SE Model
Model
Complies
Event Trace Model
Creates
Informs
Informs
Uses
Lifecycle
Metrics Reports Model
Integrated Conceptual Data Model
Creates
Creates
• Cost
• Schedule
• Risk
• People
IT System Model • Etc.
PM
System Manages • Requirements • Requirements
• Analysis • Analysis
• Verification • Verification
• Flight • Flight
Systems Software
SE SW Architecture Architecture
System System • Etc. • Etc.
20

22. Answering the Question: Are my business
processes being executed effectively without
overlap?
 Your models and metrics can identify many attributes of your enterprise that could be operating better
Ineffective Execution Overlap
 Longer than necessary schedules  Unclear lines of communication and authority
– Identification of unnecessary activities within the – More than one org is accountable for an activity
process
– System facilitating the processes activities are  Excessive cost
insufficient – Multiple organizations performing common
functions with common data
 Excessive rework – Multiple systems performing common functions
– A common data model is not being followed on common data
– Reporting is adhoc and not repeatable i.e. You
generate a custom report each time  Sub-optimal resource allocation
– Processes are not defined – Organizations, activities, data, and systems do
not clearly align with each other
 Lost or missing information
 Lack of authoritative data leading to ill or
– Data model is incomplete uninformed decision
– Activities and their data is not found in a system – Data resides in more than one system
– Data propagated into metrics and reports for
decision making from more than one system
without proper controls
21

23. Case Study: Systems Engineering Processes on
the Constellation Program
 Task
– Perform cost benefit analyses around aspects of the information systems architecture to determine
impacts of an “architected and consolidated” approach to application development and information
management
 Specific Objectives
– Process Standardization Assessment: What are the benefits over a ten year window when an
organization establishes standardized system usage with common procedures and enforces governance
versus implementation of an information system architecture without standardized procedures or
governance?
 Models
– Activity model, Data Model, System Model, Organizational Model
 Metrics
– Investment cost (Actuals)
– Projected Costs
22

24. AS-is and Desired To-Be States
Operational Rules Model Organization Model
Operational /Rules Model
Program Operational Rules Model
Project CCB
Operational /Rules Model
Program
Operational Rules Model
Operational/ Rules Model
Program
SECB
Project CCB
Operational /Rules Model
Program
SWCB
Project CCB
CxP Project CCB
Operational/ Rules Model
Program
SECB Operational /Rules Model
Program
SWCB Project CCB
Operational/ Rules Model
Program
SECB
Project CCB
Operational /Rules Model
Program
SWCB SECB
Project CCB
Operational/ Rules Model
Program
SWCB
Project CCB SECB
Project CCB
Operational/ Rules Model
Program
SWCB
SECB Operational /Rules Model
Program
SWCB Project CCB
Operational/ Rules Model
Program
Project CCB SECB SWCB
Project CCB /
Program
SECB Operational /Rules Model
Program
SWCB Surf ace SECB SWCB
SECB
Project CCB
Program /
SWCB
Project CCB
Orion Ares I MOP GOP EVA Ares V Altair Systems
SECB
SECB
Project CCB /
Program
SWCB
Project CCB
SWCB
SECB SWCB
SECB SWCB
SECB SWCB SECB SWCB
Event Trace Model
Event Trace Model
NPR 7120
NPR 7120 Activity Model
Activity Model Activity Model
Activity Model SEMP and Model
Activity
SEMP and Model
Activity As-Is To-Be Activity
SEMP NPR
Lower and Model
Level Lower and Model
Activity
Plans
SEMP
NPR
Lower and Model
Activity
SEMP
7123
Level Lower and Model
Activity
Plans
SEMP
PlansActivity Model
Lower and
SEMP Level Lower and Model
Activity
Plans
SEMP
7123
PlansActivity Model
Lower and
SEMP SE Level Lower and Model
Activity
Plans
SEMP
PlansActivity Model
Lower and
SEMP Level Lower and
Plans
SEMP
PlansActivity Model
Lower and
SEMP Processes Level Lower and
Plans
SEMP
Level Lower
Plans
Plans
Lower and
SEMP
Level Plans
Plans
Lower and
SEMP
Plans
Lower
Plans
SE Tools
SE Tools Procedures
Conceptual Data
Conceptual Data
Model
Conceptual Data
Model
• Requirements
Conceptual Data
Model Conceptual Data
• Requirements
• Analysis Model
Conceptual Data Model
• Verif•ication Model
• Analysis
Requirements
Conceptual Data
• Verif Requirements
• Flight •ication Model
• Analysis
Conceptual Data • Requirements
• Verif
• Flight Requirements
Systems •ication Model
• Analysis Reports
• Verif
• Flight
Architecture •ication
• Analysis
Systems Requirements Reports • Analysis
• Verif
• Etc. Systems •ication
• Flight
• Analysis
Architecture Requirements Reports • Verif ication
Metrics
• Verif
• Etc. Systems ication
• Flight
• Analysis
Architecture Reports
Metrics • Flight
• Verif
• Etc. Systems ication
• Flight
Architecture
Reports
Metrics
Reports Systems
Reports
Metrics
• Etc. Systems
• Flight
Architecture Reports Architecture
Metrics
• Etc. Systems
Architecture Reports • Etc.
• Etc.
Architecture
Metrics Metrics
Metrics
• Etc. Metrics
23

25. Benefits and Cost of Process Standardization
 Assuming good governance of the standards, the cost of developing standardized processes in advance of
Cradle implementation return lower costs for rework, training and maintenance of document templates
compared to the higher cost for these functions if there are not standardized processes in place
– The analysis shows a ROI over the first 4 years of 550% which was achieved by reducing:
• rework,
• the number of queries generated
• amount of training required,
• the amount of templates required and the amount of hours required to maintain the templates
– Over a period of the next six year an additional ROI of 1,100% was achievable
This was for one set of processes using one IT system
 The Constellation Information Systems Architecture (CISA) constitutes all processes, data, and systems use
within CxP (45-systems facilitating essentially all CxP processes)
– Our study looked at these processes and systems within the context of the Cradle study and concluded
that over a 10-year period a similar order of magnitude in savings was achievable
24

26. Summary
 Defining and managing your enterprise can provide significant benefit to your ability to deliver
– Reduced cost with better cost estimates
– Shortened and more accurate schedules
– Greater technical understanding and insight
 In the end, this leads to better performance and lower risk
25