Participate in our next event !
CESAM Community regularly organizes events. Our next event will be the Complex Systems Design & Management (CSD&M) conference in December 2022.
CSD&M Paris 2022
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):
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:
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 development2As a good practice, each systems architect shall always try to quickly understand whether a given system development project is only project-oriented and not project/product-balanced. This can be done by analyzing the words used within the project meetings. If the project team speaks only of agenda, milestones, activities, contractual relationships, deliverables, etc., without any reference to the underlying product, one can easily deduce a project-orientation for the project. This is statistically an important risk for the project since it does not fully master the product it is developing. .
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.