“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

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

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

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

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

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!

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!

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!

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!

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!

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!

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

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!

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!

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

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

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!

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

“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”! [*]

Thank you! Ken Griesi Office 619.758.7823 kgriesi@mitre.org Walter Wilson Office 805.348.2069 walter.l.wilson@lmco.com

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.