The "Three Systems" Approach

This article has been brought to you by Project Performance International as part of the PPI SyEN Newsletter. For the complete newsletter and past editions, please click here

Abstract

Key aspects of systems engineering are problem framing and understanding the systems with which the system of interest (SoI) (the system being “engineered”) interacts. Classic systems engineering presumes that the SoI “looks up” to the system into which the SoI fits, which is, ultimately, the end user capability system. In addition, there is a third system which must be considered, often referred to as the realization system. This system is in reality a number of systems, including (among other systems) the business/enterprise system of the organization that is producing the SoI. Most often, the end user capability system and the realization system are complex (that is, a system of systems), whereas the SoI, at some level, is a complicated system.

Thus, with the “three system approach”, as in the classic three body problem 1, there is no defined way of addressing it. This article not does not attempt to provide a solution; rather it takes the Systems Approach of attempting to make sure that those creating a system solution (a SoI) are aware of the problem, and thus, empowered to address it as effectively as it is feasible to do so.

Copyright ? 2020 by Rolls-Royce PLC. All rights reserved.

Introduction

The purpose of this article is to review the range of systems that must be understood and addressed by an organization if it is to be successful in producing a “System of Interest” (SoI) that it is seeking to create or engineer. In addition to the SoI, there is the environment into which the SoI will be placed in order to deliver its value, and the enterprise system that creates it, consisting of both its capability/realization system, and the business execution that delivers the SoI.

The intent of utilizing the Three Systems Approach is to ensure the problem is fully understood.

The value of systems engineering derives from properly and completely framing the problem, and thus, improving the probability that the system being developed is successful in terms of quality, cost, and timescale (Elm and Goldensten, 2012). Defining requirements provides the criteria for success and the constraints upon the system. Requirements elicitation practice emphasizes the need to consider all stakeholders (Walden et al, 2015). This article emphasizes the need to consider the business enterprise producing the solution, and its capability to produce systems, as a stakeholder.

This article is structured as follows. First, the different types of systems that have to be considered (the “three systems” as introduced above) are defined; and the important differences between complex and complicated systems are reviewed. Second, some issues and consequences of considering these three systems are discussed:

• Development of the organization’s capability to engineer and support SoIs.
• The concern that failing to recognize the nature and state of these three systems can lead to traps hampering innovation.
• The concern that it is to consider the “business enterprise layer” in requirements flow.

Finally, it is important to understand the author’s perspective. The author works for Rolls-Royce (RR) Defence, which supplies power systems that go into platforms such as aircraft, ships, and submarines, that provide military capabilities; and also provides support services for these power systems. This solution provision gives an implicit bias on the author’s view of Systems Engineering, rather than, say, an operator of capability.

System Consideration

The full context for the System of Interest (SoI) must be considered, and the best starting point is James Martin’s classic 7 Samurai (Martin, 2004) which defined the range of systems that are involved with a given System of Interest, including the support, competing, enterprise, and realization systems.

Figure 1 shows a simplification of the “seven samurai” into three systems (Beasley and Pickard, 2020), which are the systems referred to in the title of this article.

Figure 1: Three Systems Model

The author has extended the situation considered in the “seven samurai” paper to take into account organizations with several divisions producing a range of products (Beasley and Pickard, 2018). Figure 2 shows the full range of systems involved (a total of nine, with the outer one having potentially several layers). Note that the system numbers in Figure 2 (for the first 7 systems) match the numbers in Martin’s paper. Figure 3 shows how the how the realization system is shared across the projects, each of which is associated with a specific SoI. A key point concerning Figure 2 is the S8, the business execution system which both coordinates the use of the realization system to develop, produce, service, and dispose of the solution systems, and acts as a stakeholder of those realization systems.

Figure 2: The Range of Systems involved in Creating a System

Figure 3: Realization Systems across Multiple Customer Facing Business Units (CFBUs)

An important consideration is the difference between a complex system (a system of systems) and a complicated system. A reference for this is the Cynefin framework (Snowden and Bowden, 2007). The difference matters because a different approach is needed for complex (“probe-understand-do”) compared to complicated (“understand-plan-do”) system situations. A complicated system is a typical product with multiple layers, but making a coherent whole. Given enough time, causes can be traced to effect. A complex system (and without wanting to oversimplify, all Systems of Systems can be seen as complex) includes separate elements that are “independent” and hence cannot be controlled, and cause to effect can be unpredictable.

This difference is often not appreciated (Kemp, Beasley, and Kemp, 2015), and failure to recognize the difference can lead to either very inefficient system creation (complex methods applied to a complicated situation), or worse, dangerous failure (see Kemp et al 2014 to V or not to V). (Note that INCOSE has been advised that guidance should be developed showing how to adjust the systems approach for each of these situations [see Sillitto et al. 2018]).

From the point of view of Rolls-Royce as a power system provider, these systems can be described as:

System A – the SoI. Rolls-Royce provides physical power (complicated) power system equipment, into a platform (which is mostly complicated), which in turn informs the end-use capability (System B), which is a complicated System of Systems or a capability system. Importantly Rolls-Royce also provides service solutions related to the power systems direct to the end users. This service part of the solution is more of a complex system.

System B – the environment or context system. While the immediate environment for the power system is a platform, there must be an understanding of the end-user. The end-use is a military capability (a complex system). In the UK for example, this is made up of eight capability elements: Training, Equipment, Personnel, Infrastructure, Doctrine, Organization, Information, and Logistics (TEPIDOIL) (Kemp and Daw, 2014). Note that there is significant interaction between the platform and other platform sub-systems. These interactions are produced by different enterprises (involving contractual arrangements) and have an impact.

System C is the Rolls-Royce business enterprise. The Rolls-Royce business is itself a complex system (see Figure 3); its objective is to make money, which it does by producing a range of products and services (numerous instances of System A). It constitutes both realization systems (both architecting and developing), discussed below. Program Management must ensure that a plan to deliver System A is created, and then executed, coordinating and negotiating the allocation of the realization systems and ensuring the realization systems are capable of delivery of the desired project.

Consequences and Implications

1. Enterprise capability

One part of System C is the realization system needed to create the solution. Typically, this is seen in product terms as technology readiness which is typically described as Technology Readiness Level (TRL). It is important that TRL claims are made in terms of the context in which the technology will be used (Holt and Beasley, 2011). However just as Equipment is only one element of military capability (the E in TEPIDOIL), so Technology is only one part of the enterprise realization system. This is a complex system and can be described (and architected) as a capability (Beasley and Pickard, 2020). There are three key points to consider:

• In considering capability, Figure 1 can be re-visualized with system C realization becoming the SoI, shown in Figure 4 below:

Figure 4: Three Systems shifted to Focus on Capability to Engineer Systems as SoI

• The elements of enterprise capability need to be defined. In the Rolls-Royce TEPIDOIL, this has been adjusted to conform to the Rolls-Royce engineering approach, as shown in Figure 5.

MoD TEPIDOIL Capability Elements         RR equivalent to TEPIDOIL

Figure 5: RR Engineering Capability Elements related to MoD TEPIDOIL Capability Elements

• To ensure a full consideration of capability, it is necessary to consider when the capability is utilized, depicted in the capability chessboard shown in Figure 6. This is used as a prompt to consider what is needed. Enterprise capability needs to be seen as a complex adaptive system. A complex adaptive system is both a system of systems and a complex system situation, but also one where it currently exists so it is being changed or adapted, rather than replaced. So it is important to recognize that the “target” for capability is always moving.

Figure 6: Generic Capability Chessboard – Provides a Prompt to Consider Capability Completely

The capability elements must not be considered in isolation. Instead, the connections between the elements, making value streams, must be considered.

2. Innovation

Looking at the Three Systems Model (Figure 1) can lead to insights regarding potential hazards and traps to successful innovation (Beasley and Ingram, 2020). Two types of innovation, incremental/process and disruptive innovations, were considered. Looking at the systems involved (Figure 2) a number of traps for the innovator to beware of were identified, as shown in Figure 7.

Figure 7: Common Innovation Traps

Beasley and Ingram (2020) conclude that although many innovation failures are complex and involve many factors, an ability to understand the products (Systems A), the firm and its internal capabilities (Systems B) and how these fit into the market and environment (System C) is as important for innovators as for Systems Engineers.

3. Business execution layer.

This is system S8 shown in Figure 2.

There are two issues to consider:

1. Where does the business layer fit into the variety of layers from end-user to power system components? The issue is important because the business enterprise is a complex system, and thus does not fit in hierarchically between the platform and the power system (as it would in a complicated system). It requires the business to be defined as a system in its own right.
2. The interaction between Systems Engineering and Program Management has been discussed extensively (see Rebentinsch 2017, for example). In considering Figure 3, Program Management must include defining the activities needed to achieve the SoI (System A); integrate the business needs (including its attitude to risk) with the capability needs of the end-user (System B); coordinate the allocation of the enterprise realization systems (System C); and act as stakeholder for enhancements needed to the realization systems in order for the SoI to be successful, or ensuring constraints imposed by the realization system (which will not change) flow into the requirements for the SoI. So there needs to be controlled iteration not only between System B and System A, but also between System B and System C.

Summary and Conclusions

The author is fond of saying that everything can be thought of as a system in order to gain insight and understanding. The key point to emphasize is that all of the systems involved must be considered correctly. This may at first impression appear to make the situation more confused. However, it is vital to consider the issue and ensure that appropriate understanding is achieved. Typical problems that could result if this is not done include:

1. Failure to recognize shortfall in capability. The issue of technology readiness levels (TRL) has been well understood (see for example Holt and Beasley, 2011), but the full range of capability the enterprise needs must be considered.
2. Innovation traps.
3. Complex and complicated – end user and business requirements are not a hierarchy.
4. Design for the full lifecycle.

Epilogue

The ideas presented in Figures 1-3 do make system development seem harder than just thinking of the SoI as a system of parts fitting into a bigger system. However, in reality, considering them provides opportunity. The real problem is failing to recognize the three systems, and thus not considering the whole situation, missing key constraints and opportunities to make the solution better for all stakeholders. Moreover, by considering the full context the risk of failure or expensive rework is reduced.

List of Acronyms Used in this Paper

Acronym        Explanation

PLC         Public Limited Company

RR          Rolls Royce

SoI          System of Interest

TEPIDOIL   Training, Equipment, Personnel, Infrastructure, Doctrine, Organization, Information, and Logistics

TRL         Technology Reference Level

References

Beasley, R., Cardow, I., Pickard, A., and Symons, J., 2018, The Whole Nine Yards of Systems Engineering, INCOSE International Symposium, https://doi.org/10.1002/j.2334-5837.2018.00555.x.

Beasley, R., and Ingram, C., 2020, How Systems Engineering and Systems Thinking Enable Innovation, INCOSE International Symposium (virtual) (in proceedings, not presented).

Beasley, R., and Pickard, A., 2020, The Capability to Engineer Systems is a System Itself, INCOSE International Symposium (virtual) (in proceedings, not presented).

Cowper, D., Kemp, D., Elphick, J. and Evans, R., 2014, To V or not to V – That MUST be the Question, 24th International Symposium of the International Council on Systems Engineering, Las Vegas, NV, USA.

Elm, J., & Goldenson, D. 2012. “The Business Case for Systems Engineering Study: Results of the

Systems Engineering Effectiveness Survey“. [Technical report] CMU/SEI-2012-SR-009 Software Engineering Institute, Carnegie Mellon Univ. Available at https://resources.sei.cmu.edu/library/asset-view.cfm?AssetID= 34061.

Holt, Jonathan, and Beasley, R. 2011, “That wasn’t meant to happen!” Managing the hidden risks of system novelty” INCOSE International Symposium, 21.

Kemp, D., Beasley, R. and Williams, S., 2015, “Suits you sir! — Choosing the Right Style of SE Before Tailoring to Fit“. INCOSE International Symposium, 25: 1245–1262. https://dx.doi.org/10.1002/j.2334-5837.2015.00127.x

Kemp, D. and Daw, A., 2014, INCOSE UK Capability Systems Engineering Guide, INCOSE UK.

Martin, J. N., 2004, The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems. INCOSE International Symposium, 14: 459–470. Available at https://dx.doi.org/10.1002/j.2334-5837.2004.tb00509.x 

Rebentisch, Eric, 2017. Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems for Improving Performance. Hoboken, New Jersey USA: John Wiley& Sons.

Sillitto H, Arnold E, Dori D, Godfrey P, Griego R, Jackson S, Krob D, Mckinney D, Martin J, (2018) Envisioning Systems Engineering as a Transdisciplinary Venture – INCOSE International Symposium, Washington, July 2018

Snowden, D. & Boone M., 2007, “A leader’s framework for Decision-making”, Harvard Business Review, November 2007.

Walden, D. D., Roedler, G. J., Forsberg, K., Hamelin, R. D. & Shortell, T. M. (eds.) (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Hoboken, NJ: Wiley. ISBN: 978-1-118-99940-0.

The ideas expressed in this editorial are those of the author

This article has been brought to you by Project Performance International (PPI) 

systems engineering training for project success ...

PPI SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at https://www.ppi-int.com/syen-newsletter/

The views expressed in externally authored articles are those of the author(s), and not necessarily those of PPI or its professional staff.