Applying the Systems Approach

---

Lead Author: Rick Adcock, Contributing Authors: Brian Wells, Scott Jackson, Janet Singer, Duane Hybertson, Hillary Sillitto, Bud Lawson, James Martin

---

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 concepts introduced in Overview of the Systems Approach topic. It is part of the Systems Approach Applied to Engineered Systems knowledge area (KA), which describes, primarily through five groups of activities, the application of an approach based around systems thinking to engineered system contexts throughout their lives.

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 is successful only if it enables successful outcomes for its stakeholders (Boehm and Jain 2006). 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, according to the principle of Progressive Satisfying (Hitchins 2009).

A value cycle associating the systems approach to the deliver real world stakeholder benefits is discussed in the Overview of the Systems Approach topic. A greater understanding of the value of an engineered system within its context enables agreement on the problem situation and appropriate system interventions to be created, deployed, and used overall, in turn enabling a more effective application of the systems approach. Value is fully realized only when 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. All other rights are reserved by the copyright owner.

The views in Figure 1 apply the idea of Systemic Intervention 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 this proposition cannot be a certainty. life cycle approaches to understand and manage the shared risk of tackling such problems are discussed in Life Cycle Models. The idea of Systemic Intervention comes from soft systems thinking (see Systems Approaches).

For each of the engineered system problems, the solutions agreed above must be developed such that they 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 to provide real value (Senge 1990). In systems engineering (SE) 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, that can be employed to promote a holistic approach over a life cycle.

Life cycle management provides the framework in which to take a systems approach to all aspects of an engineered system context, which includes not only the system product or service but also 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 organized. We can express 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 deploy 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 through 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 Figure 2 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. This diagram 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:

• 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.
• 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 commercial 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 Systems Engineering and Management.

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.

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 (Hitchins 2009) defines two principle related to iterations:

• Adaptive Optimizing — 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 realized from combinations of three life cycle 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 system elements;
• 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 depends 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 element 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. This topic is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It summarizes various aspects of stakeholder responsibility for acquisition and ownership during the system life cycle processes covered by such sources as the International Council on Systems Engineering Handbook (INCOSE 2012). Any of the activities described below may also need to be considered concurrently with other activities in the systems approach at a particular point in the life of a system-of-interest (SoI).

The activities described below should be considered in the context of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).

Stakeholder Responsibilities

The general principles of life cycle application discussed above apply as necessary to each application of SE. The following sections clarify the different kinds of stakeholder and the roles they take for the different system contexts discussed in the SEBoK.

Products, Services, and Enterprises

Most often, the terms "product" and "service" describe the effects that are exchanged in a customer and supplier agreement. This may be a commercial agreement, one funded publicly by a charity, or provided by a government agency. The difference between a product and a service is that a product is an artifact acquired to achieve an outcome while a service is an outcome supplied directly to a user.

The terms “customer” and “user” are often used interchangeably in engineering and management disciplines. The INCOSE Systems Engineering Handbook (INCOSE 2012) makes the following specific distinctions among the stakeholders associated with a system:

• The acquirer is the stakeholder that acquires or procures a product or service from a supplier.
• The supplier is an organization or individual that enters into an agreement with the acquirer to supply a product or service.
• The operator is an individual or organization that that uses knowledge, skills and procedures to perform the functions of the system to provide the product or service.
• The user or customer is the individual or group that benefit from the operation of the system.

These terms define the roles stakeholders take; however, they may not always lie within these distinct entities (e.g. sometimes the acquirer may also be the user). This also applies to service systems, as some of the entities may also overlap in roles. Parnell et al., (Parnell et al. 2011) offer an alternative list of stakeholders that include decision authority, client, owner, user, consumer, and interconnected.

Product systems consist of hardware, software, and humans, and they have traditionally been the focus of SE efforts. These systems are delivered to the acquirer and operated to accomplish the goals that led to the requirements for the system. These requirements were derived from the need to provide products and services to one or more users as part of an enterprise.

The delivery (supplying) of a service is indicative of the direct delivery of an outcome, which is often related to the delivery of products (e.g., a maintenance, training, or cleaning service). This is not the same as the delivery of a service system (see the discussion below).

In traditional SE, the term “service” or “service system” refers to the wider system context that describes the acquirer's need to deliver user value. In this case, the service system is a fixed system definition that dictates the manner in which the acquiring enterprise will utilize the products to enable the delivery of services to users. Product systems are designed to be integrated and operated as appropriate to enable this service to be maintained or improved as required. In this view, a service system is static and contains dedicated products, people, and resources; that is, hierarchies of products are engineered to provide acquirers with the ability to offer predefined services to users or customers.

More recently, the term "service systems" has been used to describe a system that is engineered in a manner that allows enterprises to offer services directly to users, bypassing the need to hold all of the necessary products and services within the enterprise itself. This requires the expansion of the definition of a “supplier” as follows:

• A product supplier is an organization or individual that enters into an agreement with an acquirer to supply a product or related product support services.
• A service system supplier is an organization or individual that enters into an agreement with an acquirer to supply a service system.
• A service supplier is an organization or individual that enters into an agreement with a user to supply a service.

These service systems tend to be configured dynamically to deal with problems that traditional static service find challenging to address. This view of a service system employs "late binding" with product systems that are not owned by the enterprise, but are used to enable the service to be offered as closely to given time demands as possible. This is the definition of a service system used in the Service Systems Engineering topic in Part 4, Applications of Systems Engineering.

Stakeholder Needs

One of the most critical stakeholder responsibilities is to identify the needs and requirements for the system that provides the products or services (INCOSE 2012).These needs and requirements are expressed in agreements between acquirers and suppliers.

There are other stakeholders who shape system requirements based on their needs, but who are not necessarily acquirers or suppliers. The stakeholders and the requirements engineers share the responsibility to identify their needs during the requirements process.

Acquirer/Supplier Agreements

Lawson (Lawson 2010) provides a perspective on what it means to own systems, trade in system products and services, and the implications of supply chains in respect to the value added and ownership of the systems, its products and services. INCOSE (INCOSE 2012) defines two life cycle processes related to acquisition and supply. The acquisition process includes activities to identify, select, and reach commercial agreements with a product or service supplier.

In many larger organizations, there is a tradition of system ownership vested in individuals or, in some cases, enterprise entities (groups or teams). Ownership implies the authority and responsibility to create, manage, and dispose of a system-of-interest (SoI), as well as sometimes to operate the SoI.

Product Acquire/Supply

In some industries, a supplier works directly with an acquirer to help understand the acquirer’s needs and then engineer one or more products to satisfy these needs. In certain cases, a single supplier will provide the complete worthy product system. In other cases, a supply chain will be formed to deliver product systems with a system integrator to ensure they fit together and integrate into the wider context. This is a theoretical view of product systems engineering in which the context is fixed and the product is designed to fit into it. A good systems engineer may suggest changes to the enterprise as a better way to solve the problem and then modify the product system’s requirements accordingly. However, at some point, an agreed context will be set and a product system developed to work within it.

For many commercial products, such as mobile phones, a supplier creates a representative user profile to generate the requirement and then markets the product to real users once it is realized. In these cases, the other elements of the systems approach are performed by the acquirer/user and may not follow formal SE processes. It is important that a product supplier takes this into account when considering the best manner in which to engineer a system, as additional help or support services may need to be offered with the purchased product. The idea of a supplier offering support services for users with a type of product purchased elsewhere (e.g., an auto-mechanic servicing different makes of cars) begins to overlap with the service systems context, as discussed in the next topic.

For an institutionalized infrastructure in which SoIs are entirely owned by an enterprise or parties thereof, the entire responsibility of life cycle management, including operation, is often vested with the system owners. These systems belong to the system asset portfolio of an enterprise or multiple enterprises and provide the system resources, including the planned systems that are developed during life cycle management.

Service Acquire/Supply

Organizations providing service systems need not own the individual products and services that they deliver to their users and customers. With this viewpoint, the supplied service system includes the means to identify and gain access to appropriate products or services when needed. The service systems then would then be the bundle of products and services assembled for the user; for example, assembling software applications and service agreements for a mobile phone already owned by a user. The enterprises providing service systems may, in turn, offer infrastructure services to a wide range of different technologies or application domains. This can mean that the transition, operation, maintenance and disposal activities associated with system ownership may not be embedded in the acquiring service system enterprise, and will therefore need to be treated as separate system services. More detail can be found in Product Systems Engineering, Service Systems Engineering, and Enterprise Systems Engineering, in Part 4, Applications of Systems Engineering in the Guide to the Systems Engineering Body of Knowledge (SEBoK).

The service systems engineer helps the service supplier create and sustain the service system that can be used to discover, integrate, and use specific versions of generic products or services when needed. The realization of service systems requires the ability to make use of product systems; however, these product systems are developed and owned outside of the service system. The service system must be able to gain access to a product or service when needed, as well as to interface with it effectively. The use of open interface standards, such as standard power supplies, interface connections (e.g., Universal Serial Bus (USB)), or file formats (e.g., Portable Document Format (PDF)) can help make this easier.

Enterprise Evolution

A useful distinction between product system design and enterprise system design is that “enterprise design does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly being designed” (Giachetti 2010, xiii).

The enterprise developer may also aim to optimize back stage processes (the internal operations) of an organization or an institution by exploiting advances in technology, particularly information technology (IT) and associated processes. In these cases, the engineered systems are considered to be enterprise systems.

Enterprise systems may offer products (goods) and/or services. From an enterprise engineering viewpoint, an enterprise concurrent with its product SE must not only look at the development and delivery of the products but also look at the alignment and optimization of the product delivery within the enterprise objectives. Similarly, in service SE, the main focus is on an intangible value delivery to the end-customer (externally focused: front stage), in which internal and external processes must be synchronized. However, with the rapid advances in information and communications technologies (ICT), in many cases the boundaries between internal and external processes are quite blurred. Current SE research is extending product methods, processes, and tools into the enterprise transformation and service innovation fields to exploit advances in business process methodologies and technologies.

Enterprise SE must not only do the engineering of the enterprise itself, but may also be involved in the engineering of the service systems and products systems that are necessary for the enterprise to achieve its goals.

Activity Mapping

This topic belongs to the Systems Approach Applied to Engineered Systems KA from Part 2 Foundations of Systems Engineering. Other topics about activities, from the same KA, relate to high level technical processes defined in KAs in Part 3, Systems Engineering and Management, in the following way:

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

Part 3 discusses the principles defined in each of the systems approach activities, and how they help shape the technical processes to which they are mapped.

References

Works Cited

Adcock, R.D. 2005. "Tailoring Systems Engineering Lifecycle Processes to meet the challenges of Project and Programme". INCOSE International Symposium 2005. Volume 15. Issue 1.

Boehm, B. and A. Jain. 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.

Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press.

Kruchten, P. 2003. The Rational Unified Process: An Introduction, 3rd edition. Boston, MA: 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.

Parnell, G.S., P.J. Driscoll, and D.L Henderson (eds). 2011. Decision Making for Systems Engineering and Management, 2nd ed. Wiley Series in Systems Engineering. Hoboken, NJ: Wiley & Sons Inc.

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.

Carlock, P.G. and R.E. Fenton. 2001. "System of Systems (SoS) enterprise systems engineering for information‐intensive organizations." Systems Engineering. 4(4): 242–261.

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

Rouse, W.B. 2005. "Enterprises as Systems: Essential Challenges and Approaches to Transformation." Systems Engineering. 8(2): 138-150.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 2.1, released 31 October 2019