# A Method for Modelling Business-Critical Architecture Decisions in Engineer-to-Order Companies
## 4 Results
### Introducing the Cross-Functional Architecture Matrix
#### 4.1.1 Modelling Cross-Functional Architecture  
Figure 1 illustrates how the data are modelled using the CAM method. Subsequently, its parts are described according to the letters seen in the figure. (A) The matrix splits the model into two main parts: (1) the primary technical systems and (2) secondary engineering. The primary technical systems include systems that directly serve a product function or requirement, while'secondary engineering' concerns the mapping of secondary technical systems and engineering processes that serve the primary technical systems, i.e., processes through the full value chain and across functional disciplines. Splitting the model in this way enables the identification of dependencies between the two parts. As noted by [PERSON] [52], it is only when these dependencies are addressed that one can harvest the benefits of product architectures. (B) Along the horizontal axis, the mapping highlights the primary systems and subsystems that make up the product. The sub-systems highlight the functions comprising the primary system. The segmentation of systems should be such that different functions, technological areas, or organisational sections are separated where possible. The main systems are divided into smaller sub-systems to handle the high complexity, as pointed out in the Theory of Technical Systems [53]. It allows for comparisons of the sub-systems across different projects for both halves of the matrix. In addition to sub-systems, the system layout should be represented to show the relative positioning of the systems, indicating the various interfaces and interactions between those, thus revealing critical cross-functional dependencies across primary sub-systems, which is a key part of defining an architecture [6]. The first system to map should be determined in collaboration with company stakeholders, as they possess key knowledge of which systems have a high impact on the cost and lead time. (C) In the bottom half, both the sub-systems and processes of secondary engineering should be highlighted. This is explained in more detail in step (F). (D) In this column, recent projects from the company's past portfolio are mapped along the vertical axis. The projects should be identical in both halves of the matrix. [PERSON] et al. [34] argued that, by analysing past projects, good and bad solutions can be distinguished from each other, ensuring that the good solutions are carried over to the new architecture. When choosing which projects to analyse, it is important that they share some similarities for the matrix to work. As many different sizes and types of projects exist in the ETO business, it can be difficult to create one set of rules to follow when choosing projects to include. Therefore, project selection should be considered individually for each case. In Section 4.2, we present a case study of several projects that exemplifies the selection process. (E) The appropriate mapping of individual cells is critical in allowing for the successful analysis of the variation between projects. The mapping shall visualise the individual principles or designs that are employed to achieve the given sub-system, process, or layout in the respective projects. The visualisations representing the designs or principles shall have an abstraction level that highlights the design features whose variance impacts across competence areas or secondary engineering. In practice, this abstraction level is determined iteratively with stakeholders. This illustrative modelling is key to establishing a common ground from which stakeholders across the value chain and functional areas can understand and discuss the different technical systems and engineering processes [23]. The case study presented in Section 4.2 will provide an example of a sufficient abstraction level. (F) This step describes the general principles for prioritising which processes and systems should be mapped. The fundamental principle is that not every single system or process should be mapped.