1. “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 Wilson
Ken Griesi | Walter L. Wilson

2. 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.
[*]

3. 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.  
[*]

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

5. The “Problem Space” versus the “Solution Space”
PART II
The “Problem Space” versus the “Solution Space”
[*]

6. Problem Space vs. Solution Space Our Roles as Systems/Enterprise Engineers and Architects
“Problem Space” reqts
“Solution Space” reqts
Translated reqts
Translated reqts
CONSUMERS
Customers, Sponsors, Users, etc.
NEGOTIATORS
Enterprise / Systems Engineers and Architects
PROVIDERS
Developers, Acquirers, etc.
One must analyze the stakeholder environment,
scope the problem space,
determine the desired stakeholder outcomes,
and offer solutions that achieve the outcomes!

7. The Problem Space An Overview
“Un-owned” problem
Problem Space
Problem Space Stakeholder
“Owned” problem
Interrelated problem set
Out of scope problem
Step 0: Understand the problem set, the environment, and the stakeholders!

8. The Problem Space [cont’d] Bounding the Problem Area
“Bounded” problem set
“Bounded”
sub-problem
Step 1: Bound and understand the problem area and “owners” that you will focus upon…within the greater context!

9. The Solution Space An Overview
Problem Space
Solution space bounded by the chosen problem area
“Solution Space” Stakeholder
Single Candidate
Point Solution
Out of Scope
Point Solution
Interrelated
Point Solutions
Step 2: There is almost always more than one candidate solution!

10. The Solution Space [cont’d]
Problem Space
Solution space bounded by the chosen problem area
“Good” solution
“Better” solution
“BEST” solution
Step 3: Choose the optimal candidate solution,
based upon an evaluation of the qualities to be achieved!

11. Problem Space vs. Solution Space Our Roles as Systems/Enterprise Engineers and Architects
“Problem Space” reqts
“Solution Space” reqts
Translated reqts
Translated reqts
CONSUMERS
Customers, Sponsors, Users, etc.
TRANSLATORS
Enterprise / Systems Engineers and Architects
PROVIDERS
Developers, Acquirers, etc.
One must analyze the stakeholder environment,
scope the problem space,
determine the desired stakeholder outcomes,
and offer solutions that optimally achieve the outcomes!

12. How is EE / EA related to SE / SA?
PART II
How is EE / EA related to SE / SA?
[*]

13. Systems are part of the Enterprise!
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
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!
Vision
Enterprise
Level
Objectives
Systems
Level
Goals
Systems are part of the Enterprise!

14. How is EA related to SE? A Solution Space Perspective
The Enterprise
Scope of the Enterprise Engineer /Architect
System 2
System 1
System 4
System 3
Scope of the Systems Engineer /Architect
Systems are part of the Enterprise!

15. Best Practices and Anti-Patterns
PART III
Best Practices and Anti-Patterns
[*]

16. Analyzing the Problem Space A Practical Guide
Best Practices
Anti-Patterns
Synthesis Methods
Enterprise Architecting
Systems Architecting
Analysis Methods
Social Engineering
Organizational Science
Cognitive Science
Stakeholder Analysis
SWOT Analysis
Competitive Analysis
Etc.
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

17. Best Practices Anti-Patterns
Translating Between the Solution Space & the Problem Space A Practical Guide
Best Practices
Anti-Patterns
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
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!

18. Analyzing the Solution Space A Practical Guide
Best Practices
Anti-Patterns
Analysis Methods
Stakeholder Analysis
Trade Studies
Traditional Engineering methods
Enterprise governance
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

19. “This is like déjà vu all over again!”
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!
There is a difference between “problem space” requirements and solution “space requirements”!
[*]

20. Thank you! Ken Griesi Office 619.758.7823
Walter Wilson Office

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 Mitre Corporation, San Diego.
[2] Bergman, M., Et Al. Rough and Right: Improving the Imbalance of Power in System Design. October 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.