3.2 Systems concepts: system
The word ‘system’ is from the Greek word meaning a complex, organised whole. It has been used in this sense throughout history, and the Oxford English Dictionary records examples of usage dating from the early eighteenth century. Figure 24 shows a simplified diagram of a typical system. It indicates the boundary of the system, which divides those elements that are considered to be within the boundary, and therefore part of the system, from those elements in the environment of the system. I will discuss each of these features of systems in turn.
Drawing or positioning a system boundary is a difficult matter of judgement involving decisions about what is to be included and what should be placed in the environment. The difficulty of this act of judgement reflects its importance to the success of the system, since the placement or delineation of the boundary reflects the perspective of the system's designer. For example, in the Autodesk Workcenter project the designers within the company drew the ‘boundary of the product’ around what could be placed in the box (literally). They considered that they were designing a piece of software and, of course, to some extent that was what they were doing. Had they adopted a different, broader perspective they would have included within the product boundary the consultancy needed to achieve its successful implementation. It is an easy matter to redraw the boundary of a system on paper at a very early stage of development. However, as projects progress the boundary becomes embedded in the design concept, investment is made, and it becomes progressively more difficult to alter the position of the boundary. Positioning the system boundary is vitally important in systems engineering and is recognised in BS ISO/IEC 15288 ‘Systems engineering – system life cycle processes’. This distinguishes:
the system of interest: the system whose life cycle is of interest to a particular project
enabling systems – a system that contributes to the system of interest during one or more of the stages of its life cycle but which does not contribute directly to its operation. For example, a production system may be required to realise the system. Enabling systems have their own life cycles and will probably, at one time, have been, themselves, systems of interest. The standard notes that a systems engineering project may also have to take responsibility for creating an enabling system. (ISO/IEC 15288, p. 56)
systems in the operating environment: these are systems with which the system of interest interacts when it is operational. The nature of the interaction may be goods and services, energy, or information.
The Standard's view on the relationship of these three types of system is shown in Figure 25.
My perspective is that all systems are designed. This is demonstrably the case for systems that are engineered to be of utility, but is also true of systems that are formulated for research or analytical purposes. In both instances decisions on what is included in the system, and therefore what is in its environment, and the establishment of the relationship between the elements within the boundary constitute design decisions. Therefore, whether explicitly designed or not, systems are in the eye of the beholder.
In 1928/29 the Belgian surrealist painter René Magritte exhibited a work that he called The Treachery of Images. It depicted a smoker's pipe with the cautionary label ‘Ceci n'est pas une pipe’ (This is not a pipe). Preoccupied with the flimsy veil between image and reality, Magritte was making the point that an image of a thing is not the thing itself. Magritte's image is reproduced in Figure 26 with another level of caution!
To go beyond Magritte's image and answer the question ‘What, in reality, is a pipe?’ it would be necessary to get hold of a real pipe and demonstrate it. Setting aside solipsist objections we might conclude ‘OK, that really is a pipe’. As the eighteenth century empirical philosopher John Locke stated, ‘External objects furnish the mind with the ideas of sensible qualities …’ (Locke, 1997 ) which are all those different perceptions which they produce in us. We can experience the reality of a pipe by looking at it, touching it and (perhaps especially) by smoking it and smelling it. However, none of our senses, neither singly nor in combination, can be used to detect the reality of a system.
While we may accept that knowledge is derived from our senses, nobody sees, feels, hears, tastes or smells a system. What we conceive are objects, people, information, ideas and relationships to which we give the label ‘system’. In attaching the label ‘system’ to them we are expressing explicitly or implicitly:
a purpose for the assemblage
that a relationship or set of relationships exists between the elements in the assemblage.
A system is therefore an intellectual artefact and the label ‘system’ can be used for two purposes. First, it is a convenient way of putting a conceptual boundary around a disparate set of elements. For example, ‘the public transport system’ might include within its boundary railways, air transport, buses and coaches, and taxis. Second, using the label ‘system’ suggests a (different) way of looking at the world (Boehm, 1988). The systems viewpoint is one that emphasises purpose and process.
The image shown in Figure 27(a) represents a fountain pen, but it might also be described as a system for turning thoughts into marks on paper (b) that another person can (more or less) read. The object label ‘fountain pen’ emphasises existential form, whereas the system label tells us what it is for and the transformation (thoughts into marks on paper) that it is part of. Using the systems viewpoint is extremely valuable in engineering since it can prevent premature judgements being made. Setting out on a project with the objective of ‘designing a new fountain pen’ is a very different proposition from ‘designing a system for turning thoughts into marks on paper’.
Starting from the requirement of a new system to put marks on paper might produce a solution radically different from a fountain pen. Another important attribute of the systems viewpoint is that it encourages a holistic perspective, which I will discuss in Section 3.3.
Each of the elements in the system is affected by being part of the system, and the way that the system operates would change if an element were to be removed. Elements of a system can be decomposed into a more detailed set of sub-elements that are included as part of the system. The level of analytical detail will depend on the perspective of the analyst and the purpose that he or she has in mind. The elements that should be included as part of the system's environment are those that influence the system in some important way, but over which the system has no direct control. Each element in a system can be regarded as a process, and the system itself consists of processes that are coupled together in an identifiable way. By process, I mean a set of activities that produce an identifiable output. A process may be formally defined, and in systems engineering most processes will be of this type. One of the objectives of systems engineering methodology is to make processes and their associated outputs explicit. This characteristic will be examined in more detail later.
All the elements in a system and its environment are connected in some way. The connection may be physical – raw materials, components, assemblies and products move from one element to another. But the connection or relationship can take many forms – organisational power and authority, information and political influence.
The nature and form of the relationship between the processes in a system express the intent of its designers, whether the system is utilitarian or analytical in character. Therefore, as I suggested earlier, as its creator and the identifier of the system, the engineer, researcher or analyst is an important feature of the system. This is not to imply that the whole thing is completely subjective; that would be true to an extent neither greater nor less than any other form of engineering or analysis. But it does mean that the perspective and purpose of the system's creator have to be taken into account, as Figure 27 suggests.
To summarise, a system may be formally defined as:
an intellectual artefact that consists of
an assembly of processes that are
connected in a determinable relationship, which
has a purpose that is
either utilitarian or analytical in character.
This definition is wider than that proposed in the standard – ‘a combination of interacting elements organized to achieve one or more stated purposes’ (ISO/IEC 15288, p. 4) – but has recognisably common characteristics. The main differences are that the T837_1 definition explicitly reflects the subjective character and recognises that systems thinking can be used for analytical as well as design purposes.