“TOUCH POINTS BETWEEN SYSTEMS
ENGINEERING & ENTERPRISE ARCHITECTURE”
October 31, 2009
14th Annual INCOSE Region II Fall Mini Conference
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
Ken Griesi | Walter
L. Wilson
Ken Griesi
Walter
Wilson
Disclaimers

This presentation does not necessarily
represent the views/opinions of the:
MITRE corporation
 Lockheed Martin Corporation
 U.S. Government
 CANES program
 AEA
 INCOSE
 Walter L Wilson and Associates
…or any other body with whom the presenters are
associated.

[*]
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
2
Abstract
[*]
The success or failure of any Systems Engineering endeavor ultimately depends
upon the discovery and satisfaction of requirements in the “problem
space.” These requirements ultimately inform, shape, determine, and optimize
solutions in the “solution space.” One must apply a synthesis approach to
discover such requirements and their associated stakeholders. The result, if done
correctly, is a properly bounded problem space. The bounded problem space
takes the form of an architecture and is reflective of the requirements. As a
result, the architecture provides a basis for analysis and therefore allows for the
definition of the solution space. The architecture informs the solution space
through the application of formal analysis methods. Systems engineers
commonly practice these analysis methods, for example functional
analysis. Analysis methods are prevalent in the “decomposition” or “left” side of
the traditional systems engineering vee. However, the union between the
problem space and the solution space is often overlooked in the practice of
Systems Engineering. Likewise, the artifacts used to document the union of the
two spaces are often informal or non-existent. This presentation focuses on the
theory and practice of: (1) formal synthesis methods in the problem space, (2)
formal analysis methods in the solution space, (3) the dependencies between the
two, and (4) a pragmatic approach to formally capture and document the union
of the two spaces. In this way, the presentation defines the relationship between
the principal methodologies and resulting artifacts used in the complimentary
disciplines of Architecting and Engineering.
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
3
Purpose & Agenda
Purpose:

To identify and introduce the relationship between
Enterprises and Systems, and between Enterprise
Engineering / Architecting and Systems
Engineering / Architecting
Agenda:


PART I: The “Problem Space” versus the “Solution
Space”
PART II: How is Enterprise Engineering /
Architecting related to Systems Engineering /
Architecting?

PART III: Best Practices and Anti-patterns

Summary and conclusion
4
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
PART II
5
[*]
The “Problem Space” versus the “Solution Space”
Problem Space vs. Solution Space
Our Roles as Systems/Enterprise Engineers and Architects
6
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
The Problem Space
An Overview
7
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
The Problem Space [cont’d]
Bounding the Problem Area
8
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
The Solution Space
An Overview
9
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
The Solution Space [cont’d]
10
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
Problem Space vs. Solution Space
Our Roles as Systems/Enterprise Engineers and Architects
11
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
PART II
12
[*]
How is EE / EA related to SE / SA?
How is EA related to SE?
The enterprise has a vision  The vision has
objectives  The objectives have goals  The
goals often employ systems to achieve the goals
Enterprise
Level
Systems
Level


Systems Engineers and Architects employ formal
methods and processes needed to ensure the best
solution is provided to solve the bounded
problem area!
Enterprise Engineering and Architecting do exactly
the same thing… but at the enterprise (vice
system) level!

Therefore… Enterprise Engineers and Architects help
Systems Engineers understand the greater context!
13
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
How is EA related to SE?
A Solution Space Perspective
14
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
PART III
15
[*]
Best Practices and Anti-Patterns
Analyzing the Problem Space
A Practical Guide
Best Practices


Synthesis Methods

Enterprise Architecting

Systems Architecting
Anti-Patterns


Analysis Methods

Social Engineering

Organizational Science

Cognitive Science

Stakeholder Analysis

SWOT Analysis

Competitive Analysis

Etc.
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)



Trying to solve everyone’s problems
(not bounding the solution area)
Catering to stakeholders outside of
the problem area
Relying upon traditional engineering
methods (at this early stage)
Trying to change the culture as step
#1
Doing anything without a “sponsor”
with authority
Translating Between the Solution Space & the Problem Space
A Practical Guide
Best Practices



Differentiate between “problem space”
requirements and “solution space
requirements
Use formal architecting methods and
document(s) (a.k.a “Architecture
Specification”) to show how problems and
their solutions are balanced
“Tell me what you know… tell me what
you don’t know… tell me what you
think… and tell me which is which!” –
Colin Powell
…on both sides!

Political Science
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
Anti-Patterns







Abdicating your role as the
translator/negotiator
Believing that your role is not political
Believing that the technical argument is
the most powerful
Ignoring stakeholders on either side
Allowing the development of solutions
that don’t solve a problem
Ignoring governance… or not challenging
governance when appropriate
Keeping stakeholders honest: there is
always a trade off between cost,
schedule, and quality!
Analyzing the Solution Space
A Practical Guide
Best Practices

Analysis Methods
 Stakeholder
Analysis
 Trade Studies
 Traditional Engineering
methods

Enterprise governance
Anti-Patterns






© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
Not making use of the translator (the
SE)
Not tracing requirements to the
translation artifact (a.k.a., the
Architecture Specification)
Analysis paralysis
Developing solutions that don’t solve
a problem
Ignoring governance
Not challenging governance when
appropriate
Summary & Conclusion
“This is like déjà
vu all over again!”

– Yogi Berra


One must analyze the stakeholder
environment, scope the problem space,
determine the desired stakeholder
outcomes, and offer solutions that
achieve the outcomes!
Systems are part of the Enterprise!
Watch out for anti-patterns, and try to
repeat best practices!
[*]
© Kenneth Griesi (unless noted otherwise in footnotes/bibliography)
© Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)
19
20
Thank you!
Ken Griesi
Walter Wilson
Office 619.758.7823
[email protected]
Office 805.348.2069
[email protected]
21
Bibliography & Acknowledgments
Some concepts adapted from or built upon:
• [1] Mercer, B. ‘The Blue Brief’: Thoughts on DOD Architecting. Version 3.0: 12 June
2007. Mitre Corporation, San Diego.
• [2] Bergman, M., Et Al. Rough and Right: Improving the Imbalance of Power in System
Design. October 2009. Mitre Corporation, San Diego.
• [*] SPECIAL NOTE: All images referenced by this marker are taken from Google Image
Search. Proper credit should be given where appropriate, especially for copyrighted
materials. These images may be subject to copyright.