Applying the Systems Approach

This article is part of the Systems Approach Applied to Engineered Systems Knowledge Area. This KA described, primarily through five groups of activities, the application of an approach based around systems thinking to engineered system contexts throughout their life. 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 the engineering activities this implies. This article builds on the concpets introduced in Overview of the Systems Approach.

Life Cycle

Engineered Systems provide outcomes which deliver benefits to stakeholders by helping them achieve something of value in one or more problem situations. Ultimately, a system will only be successful if it enables successful outcomes for its success-critical stakeholders (Boehm and Jain 2006). (Hitchins 2009) defines a principle of Progressive Satisfying which states that in complex real world situations value can best be provided through a continuing process of adapting the system needs and developing associated solutions in response to changing circumstances.

A value cycle associating the Systems Approach to the deliver real world stakeholder benefits is discussed in Overview of the Systems Approach. A greater understanding of the value that an engineered system contributes to 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. Value will only be fully realized when it is considered within the context of time, cost, funding and other resource issues appropriate to key stakeholders Ring (1998).

Figure 1. Ellipse Graphic (Ring 1998). © 1998 IEEE. Reprinted, with permission, from Jack Ring, Engineering Value-Seeking Systems, IEEE-SMC. Conference Proceedings.

These views take the idea of Systemic Intervention proposed by Soft Systems approaches, see Systems Approaches, and applies it to the resolution of problem situations in which one or more Engineered System solution might be required. For each turn of the cycle an agreement is made between stakeholders and developers that “an Engineered System to solve problem X with effectiveness Y in agreed conditions Z has a chance of delivering value A for which we are willing to invest cost B and other resources C”. It is in the nature of Wicked Problems that the above proposition can not be a certainty. Life Cycle approaches to understand and manage the shared risk of tackling such problems are discussed in Life Cycle Models.

For each of the Engineered System problems agreed above solutions must be developed which are effective in terms of cost, performance and other properties relevant to the problem domain. A developer must consider not only what to do, but when and how much to do in order to provide real value (Senge 1990). In systems engineering and management practices this leads to the two key concepts (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.

Life Cycle provides the management framework in which a Systems Approach can be taken to all aspects of an Engineered System context, which includes not only the system product or service but the systems to create, deploy and support it (Martin 2004). The following sections consider how the Systems Approach should be applied to an identified problem statement, within the context of the overall value cycle discussed above.

Application Principles

Concurrency

Within any application of the Systems Approach the activities of problem identification, solution synthesis and selection; solution implementation and proving and deployment, sustainment and use should be applied concurrently, reflecting their interrelationships and dependencies.

The system value cycle (Ring 1998) can be taken as a generic model of the life of an Engineered System within a problem resolution cycle driven by stakeholder value. For practical reasons it is necessary to break this life down into a set of finite stages, to allow activities to be organize. We can expressed the value cycle as six groups of questions to cycle around value, problem, and solution questions that are related to the systems approach:

1. What values do Stakeholders want/need?
2. What system outcomes could improve this value?
3. What system can provide these outcomes?
4. How do we create such a system?
5. How do we deployed and use the system to achieve the outcomes?
6. Do these outcomes provide the expected improvement in value?

The above questions focus on each iteration of the systems approach to deliver stakeholder goals within an enterprise context. Activities 1 and 6 are part of the business cycles of providing stakeholder value within an enterprise, whereas activities 2-5 can be mapped directly to product, service, and enterprise engineering life cycles. A distinction is made here between the normal business of an enterprise and the longer-term strategic activities of Enterprise Systems Engineering.

The following diagram illustrates the concurrent nature of the activities of a Systems Approach over time.

Figure 2. Activities of the Systems Approach Applied within a System Life Cycle. (SEBoK Original)

The lines on this diagram represent activity in each of the activity areas over a simple (not to scale) life cycle based on the questions above. Activities may have a primary focus in certain stages, but need to span the whole of life to ensure a holistic approach. For example, problem identification has a large input during the Problem Understanding stage, but problems are refined, reviewed, and reassessed over the rest of the life cycle. Similarly, Implement and Proving activities are conducted during the transition from Create to Use. This is only possible if Proving issues, strategies, and risks are considered in earlier stages. Figure 1 is a schematic representation of these activity mappings, sometimes called a hump diagram (Kruchten 2003).

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

1. 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 (see System Realization); and System Deployment and Use.
2. 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).
3. Activities in any of the processes may be employed in all of the stages to allow for appropriate concurrency.
4. The sequence and control of the life cycle stages and concurrent process activities must be tailored to the problem situation and commercial environment (Lawson 2010), thus leading to the selection of an appropriate life cycle model .
5. Appropriate management activities must be included in the life cycle to ensure consideration of time, cost, and resource drivers.
6. 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 Systems Engineering and Management.

Iteration

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

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.

Hitchins (2009) defines two principle related to iterations

• Adaptive Optimising, continual redesign addresses the problem space, detecting and addressing changes in situation, operational environment, other interacting systems, and other factors; it continually conceives, designs, and implements or reconfigures the whole solution system to perform with optimal effectiveness in the contemporary operational environment.
• Progressive Entropy Reduction, continual performance and capability improvement of systems in operation may be undertaken by customer or user organizations with or without support from industry, as they seek to “get the best” out of their systems in demanding situations. In terms of knowledge or information, this process involves progressively reducing entropy, going from a condition of high entropy (that is, disorder) at the outset to low entropy (order) at the finish.

In general, these two cycles of iterations can be realised from combinations of three lifecycle 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. Each evolutionary cycle provides an opportunity to examine how the solution is used so these lessons learned can be incorporated in the next iteration.

These aspects of the systems approach form the basis for life cycle models in 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 (SoI) 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.

Recursion is a technique borrowed from computer science. In computer science recursion occurs when a function calls itself repeatedly to logically simplify an algorithm. In a recursive application applied to systems, the systems approach for one system of interest is nested inside another. Examples include cases where

• trades made at one level of the system require trades to be made for a system element;
• the analysis of a system requires analysis of a system element;
• the synthesis of a solution system requires one or more sub-system elements; and
• the verification of a product system requires verification of system elements.

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 principle of recursive application and how it relates to life cycle models is described in Life Cycle Models.

Activity Mapping

The activities of a Systems Approach Applied to Engineered Systems are directly related to the high level technical processes defined in SEBOK Part 3: Systems Engineering and Management.

• Identifying and Understanding Problems and Opportunities relates to Concept Definition.
• Synthesizing Possible Solutions and Analysis and Selection between Alternative Solutions relate to System Definition.
• Implementing and Proving a Solution relates to System Realization.
• Deploying, Using, and Sustaining Systems to Solve Problems relates to Product and Service Life Management.

The principles defined in each of the systems approach activities and how they help shape the technical processes in each of these areas are discussed in Part 3.

References

Works Cited

Boehm B and Jain A. 2006. A value-based theory of Systems Engineering. Presented at the 16th Annual INCOSE Systems Engineering Conference (Orlando FL).

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.

Kruchten, P. 2003. The Rational Unified Process: An Introduction (3rd edition), Addison Wesley.

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.

Martin, J, 2004. The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems. INCOSE 2004 - 14th Annual International Symposium Proceedings

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

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

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

Additional References

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

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

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus