TOUCH POINTS BETWEEN SYSTEMS ENGINEERING ENTERPRISE ARCHITECTURE October

“TOUCH POINTS BETWEEN SYSTEMS ENGINEERING & ENTERPRISE ARCHITECTURE” October 31, 2009 14 th 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

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 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 3 [*] defines the relationship between the principal methodologies and © Kenneth Griesi (unless noted otherwise in footnotes/bibliography) resulting artifacts used in the complimentary disciplines of Architecting © Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography)

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 Problem Space “Pro e” Spac n o i t “Solu qts re blem S reqts pace” ated Transl reqts CONSUMERS Customers, Sponsors, Users, etc. Solution Space Translate d reqts 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! 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 “Un-owned” problem Problem Space Stakeholder Problem Space “Owned” problem Interrelated problem set Out of scope problem Step 0: Understand the problem set, the environment, and the stakeholders! 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 Problem Space “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! 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 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! 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] 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! 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 Problem Space “Pro e” Spac n o i t “Solu qts re blem S reqts pace” ated Transl reqts CONSUMERS Customers, Sponsors, Users, etc. Solution Space Translate d reqts 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! 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? Vision Enterprise Level Objectives Systems Level Goals 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! Systems are part of the Enterprise! 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 Scope of the Enterprise Engineer /Architect The Enterprise System 1 Scope of the Systems Engineer /Architect System 2 System 3 System 4 Systems are part of the Enterprise! 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 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) Anti-Patterns 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 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 © Kenneth Griesi (unless noted otherwise in footnotes/bibliography) © Walter L. Wilson and Associates (unless noted otherwise in footnotes/bibliography) Anti-Patterns 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! There is a difference between “problem space” requirements and solution “space requirements”! © 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 Office 619. 758. 7823 kgriesi@mitre. org Walter Wilson Office 805. 348. 2069 walter. l. wilson@lmco. com

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.