Systems Engineering, Systems Thinking, and Systems Management in the Enterprise IT Domain

Systems Engineering

Systems Engineering has two components.

• System - a set of interrelated components working together toward some common objective.
• Engineering - applying scientific principles to practical ends, such as designing, constructing, and operating efficient and economical structures, equipment, and systems.

When we work in the Enterprise IT domain or any Software Intensive Systems ...

...systems engineering is focused on the system as a whole; it emphasizes its total operation. It looks at the system from the outside, that is, at its interactions with other systems and the environment, as well as from the inside. It is concerned not only with the engineering design of the system but also with external factors, which can significantly constrain the design. These include the identification of customer needs, the system operational environment, interfacing systems, logistics support requirements, the capabilities of operating personnel, and such other factors as must be correctly reflected in system requirements documents and accommodated in the system design. [Systems Engineering Principles and Practices, Alexander Kossiakoff, John Wiley & Sons]

So what does this mean in practice?

It means that when we start without knowing what DONE looks like, no method, no technique, a clever process will help us discover what DONE looks like once we spend a pile of money and spend much time trying out various ideas in our search for DONE. 

This means that emergent requirements mean wandering around looking for what DONE looks like. We need to state DONE in units that connect with Capabilities to fulfill a mission or deliver success for a business case.

What this doesn't mean is that we need the requirements upfront. In fact, we may need to actually what the requirements upfront. If we need to know what DONE means, those requirements must change, and that change costs much more money than writing down what DONE looks like in units of measure meaningful to the decision-makers.

So Here are Some Simple Examples of What A Capability Sounds like

• We need the capability to pre-process insurance claims at $0.07 per transaction rather than the current $0.11 per transaction.
• We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.
• We need the capability to change the Wide Field Camera and the internal nickel hydride batteries while not harming the telescope.
• We need the capability to fly 4 astronauts to the International Space Station, dock, stay 6 months, and return safely.
• We need the capability to control the Hell Fire Missile with a new touch panel while maintaining the helicopter's existing navigation and guidance capabilities.
• We need the capability to comply with FAR Part 15 using the current ERP system and its supporting work processes.

Here's a more detailed example

Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements but statements of what the system should provide regarding “abilities.”

For example, there are three capabilities needed for the Hubble Robotic Service Mission:

• Do no harm to the telescope - it is very fragile
• Change the Wide Field Camera - built here in Boulder
• Connect the battery umbilical cable - like our cell phone batteries, they wear out

How will this be done, and what are the technical, operational, safety, and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements.

To answer the questions:

• Why is this requirement present?
• Why is this requirement needed?
• What business or mission value does fulfilling this requirement provide?

Capabilities statements can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures is critical to the success of any program. Without these measures, the program may be cost, schedule, and technically successful but fail to fulfill the mission.

This is the difference between Fit for Purpose and Fit for Use.

The process flow below is the starting point for identifying the Needed Capabilities and determining their priorities. Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of all needed requirements that are missing a well-formed topology. This Requirements Architecture differs from the system's Technical or Programmatic architecture.

Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.”

These “outputs” are the mission capabilities that are fulfilled by the program. Without these capabilities, it is never clear that the mission will succeed because there is no clear and concise description of what success means. Success means providing the needed capabilities, on or near schedule and cost.

The concept of CBP recognizes the interdependence of systems, strategy, organization, and support in delivering the capability and the need to examine options and trade-offs regarding performance, cost, and risk to identify optimum development investments. CBP relies on Use Cases and scenarios to provide the context to measure the level of capability.

Here's One Approach For Capturing the Needed Capabilities

To Capture These Needed Capabilities, We Need To...

What Does All This Mean?

When we hear of all the failures of IT projects, and other projects for that matter, the first question that must be answered is 

What was the root cause of the failure?

Research has shown that unclear, vague, and often conflicting requirements are the source of confusion about what DONE looks like. Without a definitive description of DONE in units of effectiveness and performance, those requirements have no home to be assessed for their appropriateness. 

Systems Thinking and Systems Management

There are several paradigms for Systems Thinking. Ranging from Psychobabble to hardcore Systems Engineering. A group of colleagues is starting a book titled Increasing The Probability of Project Success. Several of the chapters are based on Systems Thinking.

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

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 (I have a MSSM, USC, 1980) is an umbrella discipline encompassing systems engineering, managerial finance, contract management, program management, human factors, operations research, in limitary, defense, space, and other complex systems disciplines)

Here are two references to inform the thought process in Systems Thinking

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

This book opens with an Einstein quote In the brain, and thinking is doing. As engineers, software engineering is alive and well in many domains, no matter how much we think we must do. We can plan, prepare, and predict, but the action occurs through doing.

so when we hear any suggestion, ask how this can 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. 

Cynefin is a popular approach with no units of measure of complex, complicated, chaotic, and obvious. Just soft self-referencing words. In our engineering paradigm, this approach could be more useful.

Along with these approaches 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

How to Think Like a Systems Engineer

The paradigm of systems engineering and agile development is starting to come together. "Some Future Trends and Implications for Systems and Software Engineering Processes," Barry Boehm, Systems Engineering, Volume 9, Number 1, 2006, presents an overview of how software intensive systems can be addressed through systems engineering processes.

This triggered a conversation about "what is systems engineering, and why is it applicable to software systems development?"

Thinking Like a Systems Engineer Involves Some Core Concepts

1. Conceptualizing - systems engineers see the big picture. A problem may NOT be optimally solved by breaking it into its elements and finding separate solutions. A "whole picture" needs to be constructed before solutions are proposed.
2. Requirements Analysis - requirements are the foundation of any project. Requirements analysis identifies and expresses verifiable user needs statements appropriately to guide the concept development.
3. Selecting Alternatives - systems engineering is about making trade-offs between viable alternatives. Trade studies provide an objective foundation for selecting one of the alternative solutions.
4. Optimization of the alternatives - searching for the "perfect" solution is a poor approach to problem-solving. The notion of "optimum" is related to the notion of "tradeoff." For example, synthesizing an architecture is essentially a tradeoff leading to a selected architecture.

What Does This Mean for Agile Project Management?

Agile and Systems Engineering are tightly coupled in many ways:

• Feedback
• Customer focused
• Value stream focus
• Emerging solutions
• Verifiable deliverables
• Performance-based management
• Scalable processes

C2ISR (Command and Control, Intelligence, Surveillance, and Reconnaissance) is a critical concept in the Boehm paper. This concept is closely coupled with OODA (Observe, Orient, Decide, and Act). Both are tightly connected with agile behavior. The OODA concepts emerged from fighter pilot training, and C2ISR emerged from capabilities-based planning in the defense domain.

Let's suppose agile is looking for an execution framework to move beyond the "buzz words" of manifestos, the "agile industrial complex" used to sell solutions looking for a problem to solve, and the plethora of certifications.

In that case, these paradigms are good starting points along with a Systems Engineer's "thinking" process.

In The End - Everything is a System.

Interactions between components are where the action and 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.

Resources

• Systems Management: Planning, Enterprise Identity, and Deployment
• Systemantics: How Systems Work and Especially How They Fail
• Systemantics: The Systems Bible, John Gall
• Capability-Based Planning for Enterprise Services - Capability-based planning fits naturally with Strategy-Based Planning and Business Process Improvement, May 2005.
• From Needed Capabilities to Project Deliverables - On Time, On Budget, On Specification
• Capabilities-Based Planning for Enterprise Projects, PM Summit - Capabilities-Based Planning is the capabilities needed to accomplish the mission or fulfill a business strategy. Only when capabilities are defined can we start with requirements
• Capabilities-Based Planning - defining what Done looks like for needed Capabilities through Accomplishments and their Criteria in units of measure meaningful to the decision makers starts with a Plan.
• How to Build a Credible Concept of Operations and Use it to Derive Capabilities and Features - a ConOps is a user-oriented document describing a proposed system's characteristics from the User's point of view - Thomas J. Coonce and Glen Alleman.
• Showing How to Increase the Probability of Project Success by applying the Five Immutable Principles of Project Success in Under Four Hours - Glen Alleman - GoGoAir Business Aviation, 12 July 2019.
• Agile Program Management Process - Applying Agile principles, practices, and processes to build the Release Plan for each program event and deliverables for that review.
• 5 Immutable Principles of Project Success - Project Performance Management, The Rocky Flats Story of Making the Impossible Possible.