Systems Engineering Paradigms

WHAT IS SYSTEMS ENGINEERING?

Systems engineers are one of many roles contributing to successful solutions in a wide range of domains and contexts in those domains several domains I work in. Other disciples include Risk Management, Program Planning and Controls (Earned Value Management Based), Procurement and subcontract management, all the technical disciples, and Safety and Mission Assurance.

Systems Engineers are responsible for many system concepts, architecture, and design domains. In other domains, these outcomes start with a Capabilities-Based Plan describing the Commander's Intent: based on Planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates a choice.

My USC MS in Systems Management connects Systems Engineering and Managerial Finance, including complex systems' cost, schedule, and technical performance aspects.

The analytical aspects of Systems Engineering include the analysis and management of the complexity and risk that impact the probability of program success. They decide how to measure whether the deployed system actually works as intended. They are responsible for a myriad of other facets of system creation. Systems engineering is the discipline that makes their success possible – their tools, techniques, methods, knowledge, standards, principles, and concepts. Launching successful systems can contribute to innovative and effective systems engineering.

12 Systems Engineering Principles

These principles come from Section 3.2 of Engineering Elegant Systems: Theory of Systems Engineering, A Whitepaper, Michael D. Watson, NASA Marshall Space Flight Center.

• Principle 1: Systems engineering integrates the system and the disciplines considering the budget and schedule constraints 
• Principle 2: Complex Systems Build Complex Systems
• Principle 3: The focus of systems engineering during the development phase is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the system
• Principle 4: Systems engineering has a critical role throughout the entire system life-cycle
• Principle 5: Systems engineering is based on a middle-range set of theories
• Principle 6: Systems engineering maps and manages the discipline interactions within the organization
• Principle 7: Decision quality depends on the coverage of the system knowledge present in the decision-making process
• Principle 8: Both Policy and Law must be properly understood not overly to constrain or under constrain the system implementation
• Principle 9: Systems engineering decisions are made under uncertainty accounting for risk
• Principle 10: Verification is a demonstrated understanding of all the system functions and interactions in the operational environment
• Principle 11: Validation is a demonstrated understanding of the system’s value to the system stakeholders
• Principle 12: Systems engineering solutions are constrained based on the decision timeframe for the system need.

There are Many Sources of Guidance for Applying Systems Engineering in a Variety of Domains

Here is a sample in our domain of complex system of systems

• INCOSE develops and disseminates the transdisciplinary principles and practices to enable successful systems.
• NASA Engineering Elegant Systems: Theory of Systems Engineering
• NASA's Systems Engineering Postulates, Principles, and Hypotheses guide the engineering of systems, with references on the page.
• NASA/TP-2020500364 Engineering Elegant Systems: Theory of Systems Engineering
• NASA/SP-2016-6105-SUPPL Expanded Guidance for NASA Systems Engineering Volume 2: Crosscutting Topics, Special Topics, and Appendices
• NASA Systems Engineering Handbook
• NASA/TP-20205003646 Engineering Elegant Systems: The Practice of Systems Engineering
• NASA Systems Engineering Handbook, NASA/SP-2016-6105, Rev 2
• Expanded Guidance on Systems Engineering (Volume 1)
• Expanded Guidance on Systems Engineering (Volume 2)
• Systems Engineering Research Center - Applying Systems to Acquisition Research
• DOD Systems Engineering Guidebook
• Engineering of Defense Systems Guidebook
• Department of Energy DOE G 200.2-1a
• Department of Defense Systems Engineering Guidebook
• Department of Defense Systems Engineering Guide for Systems of Systems
• Federal Highway Administration Systems Engineering for Intelligent Transportation Systems
• Naval Systems Engineering Guide
• Systems Engineering Guide for Systems of Systems 
• Naval Sea Systems Command System of Systems Engineering Guidance
• FAA Data Standards Initiative: Systems Engineering Base for Air Traffic Modernization
• DHS Systems Engineering and Standards
• National Weather Service Policy Directive: Systems Engineering
• Lawrence Livermore National Laboratory Engineering Standards Manual STD-342-100, Chapter 20-Systems Engineering
• MITRE Systems Engineering Guide

Systems Thinking, System Engineering, and Systems Management

With this background, There are several paradigms for Systems Thinking. Ranging from Psychobabble to hardcore Systems Engineering. A group of colleagues are starting a book with a working title Increasing The Probability of Project Success, several of the chapters are based on Systems Thinking.

But first some background between Systems Theory, Systems Thinking, and Systems Engineering

Systems Theory is the interdisciplinary study of systems in general, with the goal of elucidating principles that can be applied to all types of systems at all nesting levels in all fields of research.

Systems Engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering systems over their life cycles.

Systems Management is an umbrella discipline encompassing systems engineering, managerial finance, contract management, program management, human factors, operations research, in miltary, defense, space, and other complex systems disciplines)

Here are two books that inform our thought processes on this topic. 

This book is the basis of Thinking about systems. It's a manufacturing and Industrial Engineering paradigm. Software Intensive Systems also fit in here since interfaces between system components define the complex aspects of all system of systems.

This book opens with an Einstein quote In the brain, thinking is doing. As engineers, software engineering is alive and well in many domains, no matter how much we think we have to do. We can plan, prepare, and predict, but action occurs through doing. So when we hear any suggestion, ask how can this be put to work in some measurable way to assess the effectiveness and performance of the outcomes?

This is the companion mapping processes book. Systems Thinking is the process of understanding how systems influence one another within a world of systems and has been defined as an approach to problem-solving by viewing our "problems" as parts of an overall system rather than reacting to a specific part or outcome.

There are many kinds of systems. Hard systems, software systems, and evolutionary systems. It is popular to mix these, but that creates confusion and removes the ability to connect concepts with actionable outcomes. 

Along with these approaches and all the Government Systems Engineering guides are some other seminal works

• The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin
• Systems Engineering: Coping with Complexity, Richard Stevens, et al.
• Systematics: How Systems Work and Especially How They Fail, John Gall
• The Systems Bible: The Beginner's Guide to Systems Large and Small, John Gall

In The End

Everything's system. Interactions between components is where the action is and where the problems come from. Any non-trivial system has interactions that must be managed as system interactions. This means modeling these interactions and estimating the impacts of these interactions. Defining the behaviors of these interactions before, during, and after their development,

This means recognizing the criteria for a mature and effective method of managing in the presence of uncertainty.

• Recognition by clients and providers of the need to architect the system.
• Acceptance of a disciple to those functions using known methods.
• Recognition of the separation of value judgments and technical decisions between client, architect, and builder.
• Recognition that architecture is an art and a science, particularly the development, and use of nonanalytical techniques.
• Effective utilization of an educated professional staff engaged in the process of systems-level architecting.