1.1 Product and Project Systems

Before going further, we need first to introduce a distinction that will be fundamental to understand better both what is systems architecting and how to read many classical engineering issues. It indeed appears that all engineered systems are always involving two kinds of systems (see Figure 10):

the first one is clearly the product system, i.e. the integrated hardware and software¹ object which is under engineering in order to be finally constructed and put in service,
the second one is the project system, that is to say the engineering organization (or in other terms the engineers) who is designing and developing the product system.

These two types of systems are of quite different nature: the product system is usually a technicaldominant system when the project system is clearly a human-dominant system. However as shown in Figure 10, they are highly and permanently coupled during all the design & development phases of the product system: the project system typically monitors the implementation status of the product system through adapted implementation actions that are changing this implementation status.

Figure 10 – Product versus project systems

The product / project distinction does seem very simple. However it appears in practice that most of engineers are thinking in terms of project activities realization and not of product characteristics achievement. Many engineering issues are thus coming from the fact that system development project are often too project system-oriented and not enough product system-focused. One must indeed understand that there are two totally different ways of managing a system development:

Management mode 1 – project system management: this first management mode – also the most common – groups all classical project management activities where a system development project is followed by means of a project agenda and a task achievement monitoring.
Management mode 2 – product system management: this other management mode intends to monitor the progressive achievement of the desired product system, which is followed by means of systems architectural views

These two management modes shall of course not be opposed, since they are fully complimentary. A key good practice, on which systems architecting relies, claims in particular that these two modes of management – respectively based on a project agenda and on systems architectural views – are both mandatory in the context of complex systems development (see sections 1.2 and 1.3 below).
The project system management mode is indeed not sufficient for ensuring the good achievement of the product system quality & performance when such a product became complex. One unfortunately observes in practice (see next section) too many situations where complexity is so high that project teams are not able anymore to master their product. These teams are thus discovering too late that they will never deliver the expected product within its cost, delay, quality and/or performance limits. The key motivation of systems architecting is just to provide to these engineering teams new product system-oriented tools to better master their complex integrated system development².

Typical examples of product and project issues table

Table 1 – Typical examples of product and project issues

Note also finally that most of engineering issues occurring with complex systems can be classified into two categories, according to the product/project distinction, that is to say on one hand, product problems, referring to purely architectural flaws leading to a bad design of the product, and on the other hand, project problems, referring to organizational issues leading to a bad functioning of the project. Table 13 above provides an overview of typical such problems. All details on examples and analyzes illustrating these different complex systems issues can be found in Appendix B.

1.1 Product and Project Systems

1.1 Product and Project Systems

TABLE OF CONTENTS