Applying the Systems Approach

The Systems Approach is described in the SEBoK primarily through five topics: Exploring a Problem or Opportunity, Systems Analysis Approach, Synthesis of a System, Proving a System, 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 and to the levels of system relationship and detailed management and engineering activities this implies.

Concurrency

Normally, the five topics of the systems approach are applied concurrently , reflecting their interrelationships and dependencies. (Ring, 1998) defines a System Value Cycle which describes three levels which a systems approach must consider to deliver real world benefit: 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. (INCOSE, 2011) In System Engineering and Management practices, (INCOSE, 2011), this leads to the creation of:

life cycle : stakeholder value and problem resolution described as a set of Life Cycle Stages over which problems can be explored and resolved, and resources managed.
life cycle process : 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.
Lifecycle Processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a lifecycle, 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), 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 this cycle we must consider 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 have been implemented in Systems Engineering are discussed in System Life Cycle PRocess Models: Vee amd System Life Cycle Process Models: Iterative.

Iteration

The Systems Approach can be apply in an iterative way to move towards an acceptable solution to a problem situation, within a larger cycle of stakeholder value.

(Hitchins, 2009) defines a principle of Adaptive Satisficing, by which a Systems Approach is applied iteratively to move towards 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, which 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
Have we created such a system? = Proving (Verification)
Have we deployed the system 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 exhausted.

The above 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 Systems Engineering, or applications of a Systems Approach to the Enterprise is a matter of debate amongst the systems community, see Enterprise Systems Engineering and System of Systems.

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 of one of three types (Adcock, 2005):

Sequential: a single application of the systems approach is sufficient, with iteration between the stages to solve detailed issues as they arise.
incremental : successive versions of the sequential approach for a solution concept. Each increment adding function 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 to 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 better understanding of a situation; product system and/or service system solutions to operational needs; enabling systems to support an aspect of the product or service lifecycle; or enabling systems used directly by the enterprise system .

Each of these system may be identified as a system of interest (soi) , and require the application of a 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 system approach for one SoI is nested insider 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 we must reach a level at which an application of the approach 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 Systems Engineering to levels of system element , with each application representing a system project . (Martin,1997) describes the recursive application of System Engineering 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 will provide a direct mapping of the various principles of the Systems Approach to the elements of Systems Engineering and a direct link to the descriptions of those elements. The following subsections are organized according to the Systems Approach principles above with a discussion of how these principles are linked to the elements of Systems Engineering.

Exploring a Problem or Opportunity

The problem or opportunity to be addressed can best be determined by conducting a Mission Analysis and by determining the requirements from the stakeholders. See the section in Part 3 called Mission Analysis and Stakeholders Requirements to determine how this is done. Hence, the Systems Approach principle of Exploring a Problem or Opportunity engenders the Systems Engineering concepts of Mission Analysis and Stakeholder Requirements.

System Analysis Approach

Identification of the Elements of the System

Within the Part 3 section called 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 beco me physical objects eventually. This progression from the abstract to the concrete is discussed by Hitchins (Hitchins, 2009, p. 59). The relationships between these elements is also defined and their interactions. The architectural relationships will also be defined. When the abstract elements are transformed into defined elements, these two set of elements are also said to be coupled. According to Blanchard and Fabrycky (Blanchard and Fabrycky, 2006, Chapters 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 Architectural Design section groups of elements are defined that can perform a given function. These groups of elements lead to the concept of a subsystem. According to this section, subsystems are identified during the synthesis process. A set of criteria are defined for grouping elements. Hence, the Systems Approach concept of grouping gives rise to the Systems Engineering concept of subsystems.

Identification of the Boundary of a System

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

Identification of the Interactions Among the Elements

The Architectural Design section also has a subsection called "Concept of Interface". The Systems Engineering concept of interface is the application of the Systems Approach principle of interactions among elements. The Architectural Design section distinguishes between physical interfaces and functional interfaces. This section emphasizes that both types of interfaces should be considered in the system definition.

Synthesis of a System

The Architectural Design section has a subsection called "Designing Physical Candidate Architecture". This subsection describes the process of synthesis and provides a set of criteria for synthesis. According to this subsection, “synthesis is done by grouping the leaf system elements to constitute a group of (sub) systems.” First, in compliance with the principles of the Systems Approach, the Systems Engineering process of synthesis does not begin with a defined system; there is only a problem or opportunity that has been defined. There may be some existing elements (see Identification of the Elements of a System, above) that will eventually become part of a system, but that fact does not change the approach. The objective is to progress from the problem to a defined system; but how does that happen? When a set of assets becomes a system, the latter is called a respondent system, according to Lawson (Lawson, 2010, Chapter 1). The set of assets and the respondent system are said to be coupled. Complexity makes the process even more 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 the necessary process.

Proving a System

The System Realization section notes that both Verification and Validation are components of the System Realization process. Implementation and Integration are the other two. These two processes are the application of the Systems Approach principle of Proving the System.

Verification

According to the System Realization section of Part 3, the Systems Engineering 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 it meets its performance requirements. This process is the Systems Engineering implementation of the Systems Approach principle of verification.

Validation

The Systems Approach section of Part 3 also provides detail as to how the Systems Engineering process of validation meets the Systems Approach principle of validation. Finally, 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 identified in the beginning.

Owning and Making Use of a System

The System Deployment and Use section of Part 3 also provides detail about the Systems Engineering 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 the Systems Engineering processes of Conceptual Design, Preliminary Design, and Detail Design.

References

Citations

Framework for Tailoring Systems Engineering Lifecycle Processes, INCOSE International Conference 2005.

Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.

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

Hitchins, D. 2009. What are the General Principles Applicable to Systems? Insight. International Council on Systems Engineering.

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

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

Martin J. N. 1997. Systems Engineering Guidebook. CRC Press, 1997. ISBN 0849378370

Ring, J., "Engineering Value-seeking Systems." IEEE-SMC Conference Proceedings, 1998

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

Primary References

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

Hitchins, D. 2009. What are the General Principles Applicable to Systems? Insight. International Council on Systems Engineering.

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

Additional References

Blanchard, B. & Fabrycky, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.

Article Discussion

I would expect to see some version of the "Hump Diagram" to help explain the concurrent nature of processes across a lifecycle. This would help illustrate the concept of concurrency. A generic version could be drawn and used in this section.

A number of typographical errors corrected e.g. "concurently", "engieering".

(Davidz, 8/22)

Stakeholder value seems like a key topic, should this be included as a glossary term for this page?
Hyperlinks would be helpful for the "links to other topics"
In the Concurrency section, do you want all the numbers to be "1" for the fundamental principles? (Fixed)

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Radcock 14:12, 23 August 2011 (UTC)