Applying the Systems Approach

The Systems Approach is described in the SEBoK primarily through five topics: Identifying and Understanding Problems and Opportunities, Synthesizing Possible Solutions, Analysis and Selection between Alternative Solutions, Implementing and Proving a Solution, and Owning and Making Use of a System. Together, understanding these five topics enables the application of systems thinking to an engineered system throughout the life of that system. This article describes how the systems approach relates to both the dynamics of problem resolution and stakeholder value over time, as well as to the levels of system relationship, detailed management, and engineering activities this implies.

Application Principles

Concurrency

Normally, the five topics of the systems approach are applied concurrently , reflecting their interrelationships and dependencies. Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit. These three levels are stakeholder value, system problem situation (or purpose), and system solution (or intervention). Value will only be fully realized when it is considered within the context of time, cost, and other resource issues appropriate to key stakeholders. A developer must consider not only what to do, but when and how much to do in order to provide real value (Senge 1990).

Greater understanding of the value that an engineered system is to offer enables more effective application of the systems approach, which in turn enables the problem situation to be agreed to and appropriate system interventions to be created, deployed, and used (Ring 1998). All of these activities happen concurrently. Efficient application of the systems approach requires awareness of constrained time and funding resources to realize desired value. In systems engineering (SE) and management practices this leads to the creation of (INCOSE 2011):

life cycles : stakeholder value and problem resolution described as a set of life cycle stages over which problems can be explored and resolved, and resources can be managed.
life cycle processes : systems of activities focused on creation and sharing of knowledge associated with the systems approach, which can be employed to promote a holistic approach over a life cycle.

For the generic systems approach, the following fundamental principles apply:

A life cycle has groups of stages which cover understanding stakeholder value; exploration of a problem situation (see System Definition); creation of a system solution, including analysis, synthesis, and proving (see System Realization); and System Deployment and Use.
Life cycle processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a life cycle (e.g., requirements, architecture, verification, and validation).
Activities in any of the processes may be employed in all of the stages to allow for appropriate concurrency.
The sequence and control of the life cycle stages and concurrent process activities must be tailored to the problem situation and commerical environment (Lawson 2010), thus leading to the selection of an appropriate life cycle model .
Appropriate management activities must be included in the life cycle to ensure consideration of time, cost, and resource drivers.
In focusing on the creation of a specific system of interest (SoI) to provide solutions within the cycle, it is important to recognize the need to employ the right balance between reductionism and holism by considering the appropriate system context.

The ways in which this idea of concurrent process activity across a life cycle has been implemented in SE are discussed in System Life Cycle Process Models: Vee and System Life Cycle Process Models: Iterative.

Iteration

The systems approach can be applied in an iterative way to move towards an acceptable solution to a problem situation within a larger cycle of stakeholder value.

Hitchins (2009) defines the principle of adaptive satisficing wherein a systems approach is applied iteratively to move towards the resolution of real world stakeholder needs. The system value cycle (Ring 1998) can be expressed as six groups of questions to cycle around value, problem, and solution questions that can be related to the systems approach:

What value do Stakeholders want/need? = Explore Problems and Oppourtunities
What system outcomes could improve this value? = System Analysis
What system can provide these outcomes? = Synthesis
Has such a system been created? = Proving (Verification)
Has the system been deployed to achieve the outcomes? = Proving (Validation)
Do these outcomes provide the expected improvement in value? = Ownership and use

This cycle continues until statekholders are satisfied or resources are exhausted.

The above questions focus on the iteration of the systems approach to deliver stakeholder goals within an enterprise context. Whether the first and last questions in this cycle are applications of SE or applications of a systems approach to the enterprise is a matter of debate within the systems community (see Enterprise Systems Engineering and Systems of Systems (SoS)).

The systems approach can be applied to multiple systems within an engineered system context, as discussed below. At each level, the approach may be applied iteratively to cycle between what is needed and versions of the solutions within a life cycle model. In general, these iterations are one of three types (Adcock 2005):

Sequential: With iteration between the stages to solve detailed issues as they arise, a single application of the systems approach is sufficient.
incremental : Successive versions of the sequential approach are necessary for a solution concept. Each increment adds functionality or effectiveness to the growing solution over time.
evolutionary : A series of applications of the sequential approach for alternative solutions intended to both provide stakeholder value and increase problem understanding.

These aspects of the systems approach form the basis for life cycle models.

Recursion

The stakeholder value, problem resolution, and system creation aspects of the system value cycle may each require the use of a focused systems approach. These might be soft systems to prove a better understanding of a situation, product systems and/or service systems solutions to operational needs, enabling systems to support an aspect of the product or service life cycle, or enabling systems used directly by the enterprise system .

Each of these systems may be identified as a system of interest and require the application of the systems approach. This application may be sequential (the start of one system approach dependent on the completion of another) or parallel (independent approaches which may or may not overlap in time), but will often be recursive in nature. In a recursive application, the systems approach for which one system of interest is nested inside another, this might be:

The exploration of a problem situation requires a stakeholder exploration team.
The analysis of a problem statement requires some system model.
The synthesis of a solution system requires one or more sub-system elements.
The verification of a product system requires a test facility.
The deployment of a product system requires operator training.
The use of a service system requires communication infrastructure.

In each case, the "outer" system approach may continue in parallel with the "inner" to some extent, but will be dependent on key outcomes for its own progress.

As with all recursive processes, at some stage the application of the approach must reach a level at which it can be completed successfully. This then "rolls up" to allow higher levels to move forward and eventually complete all nested applications successfully.

The INCOSE Systems Engineering Handbook (INCOSE 2011) describes a recursive application of SE to levels of system elements , with each application representing a system project . Martin (1997) describes the recursive application of SE within a product system hierarchy until a component level is reached, at which point procurement of design and build processes can be used to create solution elements.

The concept of recursive application and how it relates to life cycle models is described in Systems Engineering and Management.

Systems Approach and Systems Engineering

This section provides a direct mapping of the five topics in the systems approach to the elements of systems engineering and a direct link to the topics describing those elements.

Exploring a Problem or Opportunity

The problem or opportunity to be addressed may be determined by conducting a mission analysis and by determining the requirements of the stakeholders. See Mission Analysis and Stakeholder Needs and Requirements for more information about how this is done. Hence, the systems approach principle of exploring a problem or opportunity engenders the SE concepts of mission analysis and stakeholder requirements.

System Analysis Approach

Identification of the Elements of the System

Within the activities described in the topic Architectural Design, the functional architecture is defined and the physical elements are allocated to the elements of the functional architecture. In the early phases some elements are identified, but these elements are not physically visible; they are abstractly defined. Perhaps only their functions are known at this time. Yet, these functions eventually become physical objects. This progression from the abstract to the concrete is discussed by Hitchins (2009, 59). Relationships between elements, as well as architectural relationships, are also defined. When the abstract elements are transformed into defined elements, these two sets of elements are also said to be coupled. According to Blanchard and Fabrycky (2006, chap. 3-5), when translated into systems engineering terminology, these stages of system evolution are known as conceptual design, preliminary design, and detail design.

Grouping of Elements

Also within the activities identified in Architectural Design, groups of elements are defined that can perform a given function. These groups of elements lead to the concept of a subsystem. According to Architectural Design, subsystems are identified during the synthesis process using a set of criteria for grouping elements. Hence, the systems approach concept of grouping gives rise to the SE concept of subsystems.

Identification of the Boundary of a System

The Architectural Design topic also describes the concept of the system of interest. The boundary of the system of interest is the interface between the system of interest, its environment, and other systems. According to Checkland (1999, 312), a boundary is "the set of elements that define the limit of the System of Interest (SoI)." Hence, the boundary of the system of interest in SE fulfills the systems approach principle of a boundary.

Identification of the Interactions Among the Elements

The Architectural Design topic describes the concept of interfaces . The SE concept of interface is the application of the systems approach principle of interactions among elements. The Architectural Design topic distinguishes between physical interfaces and functional interfaces, both of which should be considered in the system definition.

Synthesis of a System

The Architectural Design topic identifies the need to design a physical candidate architecture. Such design is the process of synthesis and should include a set of criteria to guide it. Synthesis is done by grouping the leaf system elements to constitute a group of (sub) systems.

In compliance with the principles of the systems approach, the SE process of synthesis does not begin with a defined system; there is only a problem or opportunity that has been defined. There are often some existing legacy elements that will eventually become part of a system, but at an abstract level, that fact does not change the approach. The objective is to progress from the problem to a defined system; but how does that happen? According to Lawson (2010, chap. 1), when a set of assets becomes a system, the latter is called a respondent system. The set of assets and the respondent system are said to be coupled. Complexity makes the process non-linear. As emergent properties begin to be observed, changes may need to be made in component definition and perhaps even in the architectural arrangement. Hence, iterative definition becomes necessary.

Proving a System

The System Realization Knowledge Area notes that both verification and validation are components of the system realization process. Implementation and integration are the other two components of the process. These two processes are the application of the systems approach principle of proving the system.

Verification

According to System Realization, the SE verification process uses the results of the system design, including requirements, to determine whether the system is designed in the way it was intended to be designed and whether it meets its performance requirements. This process is the SE implementation of the systems approach principle of verification.

Validation

The Systems Approach Knowledge Area explains how the SE process of validation meets the systems approach principle of validation. With good judgment and patience, a system will emerge. This system must be proved, as previously discussed. If all has been successful, the system will solve the problem or exploit the opportunity that was previously identified.

Owning and Making Use of a System

The System Deployment and Use Knowledge Area explains the SE aspect of deployment and use to apply the systems approach principle of the same name. Factors include transition to deployment, maintenance, logistics, and system operation.

Linkages to other topics

This topic is linked to Mission Analysis, and Stakeholder Needs and Requirements, System Realization, and Architectural Design: Logical and Architectural Design: Physical.

References

Citations

Blanchard, B. and W.J. Fabrycky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ, USA: Prentice Hall.

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.

Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight. 12(4).

INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College.

Martin J. N. 1997. Systems Engineering Guidebook. Boca Raton, FL, USA: CRC Press.

Ring, J., 1998. "A Value Seeking Approach to the Engineering of Systems." Proceedings of the IEEE Conference on Systems, Man, and Cybernetics. p. 2704-2708.

Senge, P. 1990. The Fifth Discipline: The Art and Practice of the Learning Organization. New York, NY, USA: Doubleday/Currency.

Primary References