Yes systems engineering, you are a discipline


Published on

Systems engineering is currently characterized by conflicting and contradictory opinions on its nature. The paper begins by describing the evolution of systems engineering in the National Council on Systems Engineering (NCOSE)/ International Council on Systems Engineering (INCOSE) and the difficulty in defining and differentiating systems engineering as a discipline. The paper then identifies and discusses six different and somewhat contradictory camps or perspectives of systems engineering. After identifying the cause of the contradictions the paper suggests one way to reconcile the camps is to dissolve the problem to distinguish between the activity known as systems engineering and the role of the systems engineer with a return to the old pre-NCOSE systems engineering paradigm. The paper then continues by testing the hypothesis and shows that systems engineering is a discipline that can be differentiated from other disciplines. However, it is not a traditional engineering discipline.

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Yes systems engineering, you are a discipline

  1. 1. 2012Yes systems engineering, you are a discipline Joseph Kasser Derek Hitchins Revision 1.0
  2. 2. Topics 2012• The undesirable situation• Seven systems engineering camps• Reconciling the camps• SETR and SETA• The systems engineering process• Conclusions• Simplifying the SEBoK• The ‘T’ shaped systems engineer2
  3. 3. The undesirable situation 2012• The role of the systems engineer in the workplace depends on the situation.• The role of the systems engineer has evolved over time – it is different in practically every organisation – has various degrees of overlap with the roles of project managers and personnel in other disciplines.• Definitions and descriptions of systems engineering comprise different interpretations of the broad raft of activities that systems engineers might undertake according to their role in the workplace.• Myths and defects abound unquestioned• The problem is to convert the undesirable situation into a desirable situation – A common consensus on a GUTSE (Friedman, 2006)3
  4. 4. Seven camps in systems 2012 engineering1. Life cycle2. Process Discussed in Kasser and 3. Problem Hitchins 20114. [Meta-]Discipline Updated in the paper 20125. Domain6. Systems thinking and non-systems thinking7. Enabler4
  5. 5. Which process? 2012 P ro b le m A p p re c ia tio n User In s ta lla tio n & O p e ra tio n a l r e q u ire m e n ts d e fin itio n v a lid a t io n s y s te m A llo c a te d Propo sed S u p p lie d S o lu tio n A b s tra c tior e q u ir e m e n t s n c h a ra c te r is tic s S o y s te m n R e a lis a tio n s lu tio Lo cal S y s te m A r c h ite c tu ra l In te g r a t io n & In te g r a te d r e q u ir e m e n ts re q u ir e m e n ts & c o n s tr a in ts d e fin itio n d e s ig n v e rific a tio n s y s te m A llo c a te d P ro p o se d S u p p lie d r e q u ir e m e n t s c h a ra c t e r is t ic s c o m p o n e n ts Lo cal Com ponent Com ponent Com ponent r e q u ir e m e n ts re q u ire m e n ts d e s ig n b u ild & te s t C o m p o n en ts & c o n s tr a in ts a 11 1 S o lu tio n D e v e lo p m e n t Process Input Requirements Analysis Systems Analysis • Analyse Missions & Environments • Identify Functional Requirements & Control • Define/Refine Performance & Design Constraint Requirements • Select Preferred Alternatives • Trade-off Studies Requirements Loop • Effectiveness Analysis Functional Analysis/Allocation • Risk Management • Decomposition to Lower-Level Functions • Configuration Mgmt • Allocate Performance & Other Limiting • Interface Management Requirements to Lower-Level Functions • Data Management • Define/Refine Functional Interfaces (Internal/External) • Performance Based Progress • Define/Refine Functional Architecture • Performance Measurement – SE Master Schedule Design Loop – Tech Perf Measurement – Technical Reviews Synthesis • Transform Architectures (Functional to Physical) Verification • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions PROCESS OUTPUT5
  6. 6. The systems engineering 2012 process (1970)6
  7. 7. The systems engineering 2012 process (2010)More steps 7
  8. 8. International process 2012 Start End 6‐88
  9. 9. 2012 The problem campSystems engineering “concentrates onthe design and applications of the wholeas distinct from the parts … looking at aproblem in its entirety, taking into accountall the facets and all the variables andrelating the social to the technical.” (attributed to Simon Ramo, 1973) 9
  10. 10. The discipline camp 2012• Meta-discipline• Multiple disciplines and domains• Breadth and depth of knowledge• T- shaped systems engineer10
  11. 11. Enabler camp 2012• Systems engineering is – Is a philosophy and a way of life” (Hitchins, 1998). – The application of holistic thinking to: • see [missing] connections where others don’t • develop an understanding of a situation • identify the real problem • identify an appropriate solution • plan the implementation of the solution • predict probable futures, risks and their mitigation.11
  12. 12. Enabler camp 2012• Systems engineering is the “engineering discipline governing the design, evaluation, and management of a complex set of interacting components to achieve a given purpose [function]” – George Friedman,199612
  13. 13. Parable of blind men and elephant* 2012“…And so these men of IndostanDisputed loud and long,Each in his own opinionExceeding stiff and strong,Though each was partly in the right,And all were in the wrong! MORAL.So oft in theologic wars,The disputants, I ween,Rail on in utter ignoranceOf what each other mean,And prate about an ElephantNot one of them has seen!” * Yen, D. H., The Blind Men and the Elephant, 2008,  13, last accessed 26 October 2010
  14. 14. Reconciling the camps 2012 • SETR • SETA – systems engineering - – systems engineering - the role the activity – what systems engineers – can be performed by do in the workplace anyone – Growing into Meta- • SETA maps into SETR discipline – Can be differentiated – Combination of SETA from other disciplines and non-SETA • See paper* for how SETA meets the – Cannot be differentiated requirements for being from other disciplines a discipline* Kasser and Hitchins, 2012 14
  15. 15. Systems engineering paradigms* 2012• SETR: activities performed by personnel known as systems engineers. – Examples are network systems engineering, control system engineering, communications systems engineering, etc. – In many instances the type of system is dropped from the title. – This systems engineering overlaps other disciplines and the exact role depends on the situation • Broad range of competencies• SETA: activities concerned with problem identification and solution realization at the system level – Kasser and Hitchins, 2009 – This systems engineering is an enabling discipline (like mathematics) for remedying undesirable situations * Kasser and Hitchins, 201215
  16. 16. SETA in Singapore: systems 2012 approach works* • Social System – Public Housing • Economic System – Industrial Development • Defence System – Air Defence Dr Goh Keng Swee (1918-2010) • Minister • Visionary • Economist*LUI Pao Chuen, Singapore: An Example of Large Scale Systems  • Systems ArchitectEngineering, APSEC, 23 March 2007. • one tool he used was Systems 16 Engineering The Activity
  17. 17. SETA 2012Modifying George Friedman’s definition• SETA may be considered as a “discipline governing the design, evaluation, and management of a complex set of interacting components to achieve a given purpose [function]” by the application of holistic thinking.• SETA remedies George’s undesirable situation, namely the lack of a GUTSE (grand unified theory of systems engineering)** George J. Friedman (Friedman, 2006) called for the development of a GUTSE echoing (Hill and Warfield, 1972) who wrote “development of a theory of systems engineering that will be broadly accepted is much to be desired.” (Kasser, INCOSE, 2007)17
  18. 18. SETA 2012• Cooking a meal – Meals emerge from both the process and the combination of, and the interaction between, the ingredients. – The best ingredients will not save a meal that was over-cooked or under-cooked.• Diagnosing an illness – Good physicians consider the symptoms holistically in the context of the physiology of the patients and their environments.• Organising a conference – Conference emerges from the combination of, and interaction between, the location, speakers, reviewers, delegates, and other entities.• Solving crimes – Detectives, upon investigation, find a variety of clues which (should) lead to the perpetrator18
  19. 19. Conclusion: SETA and SETR 2012• Resolves the conflicts and contradictions in the current state of systems engineering• The traditional activities known as systems engineering can be described in terms of SETA and SETR.• SETR is the job title for a person who performs a mixture of SETA and non-SETA.• SETA is an enabling discipline that is used in other disciplines and domains.• SETA as a discipline can be differentiated from other disciplines.• Resolves issues due to the overlap between systems engineering and project management.19
  20. 20. Processes 2012• No such thing as a Systems Engineering Process. It is the – System Acquisition and Development Process • In which SETA takes place – System life cycle • In which SETA takes place• Domain knowledge is critical for success – Problem, solution and implementation20
  21. 21. The systems engineeringConsequences of not having a 2012 process (1970) CONOPS Lack of a common vision of the solution (Wednesday 1000) 21
  22. 22. SEBoK 2012• SETR – All disciplines that overlap systems engineering – All domains in which SETR is done • Approach rejected in Kasser and Massie, INCOSE, 2001• SETA – Converting complexity to simplicity – Converting undesirable situations into desirable situations • Problem identification and remediation by the application of holistic thinking – systems thinking, analysis and critical thinking – A set of thinking tools used in addition to domain competency22
  23. 23. SETR: Building artificial complexity 2012 23
  24. 24. Topics 2012• The undesirable situation• Seven systems engineering camps• Reconciling the camps• SETR and SETA• The systems engineering process• Conclusions• Simplifying the SEBoK• The ‘T’ shaped systems engineer24
  25. 25. The ’T’ shaped professional 2012 • People possessing these Ability to apply knowledge  skills are Systems engineering – able to shape their knowledge to fit across situations the problem at hand rather than insist that their problems appear in a Discipline particular, recognizable form – needed when problems cross domains• Research environment • Dorothy Leonard-Barton (1995),• Deep knowledge of one Wellsprings of Knowledge: Building domain and Sustaining the Sources of Innovation, Harvard Business• Know how their disciplines School Press interact with others – Drawing is Figure 3.5 “Telephone” or Chinese whispers”25
  26. 26. The ‘T’ shaped systems 2012 engineer • Characteristics – Questions  Breadth in systems engineering – – and  Depth in one or two disciplines Breadth in other disciplines • – comments? Not what was in original reference Think about educational requirements – How deep? • Change perspective • Rotate the ‘T’ 90 degrees26