Reflections on system architecting

Combining technical, market and customer value

Source: Mikroniek 2018-4 - A system architecture, according to Wikipedia, is the conceptual model that defines structure, behaviour and other aspects (or ‘views’) of a system. Such a model can be used to guide the design of a system and determine its success. In the precision engineering and mechatronics domain, where systems can be very complex, system architecting, i.e., the art of defining and maintaining a system architecture, is a crucial discipline. Ger Schoeber, manager Innovation & Technology at Hotraco and course leader of the famous “System architecting” training course, presents some reflections on this very special (precision) talent.

The pioneer in the field of system architecting, at least from the Dutch perspective, is Gerrit Muller, who has worked at Philips Medical Systems, Philips Research and ASML and is now a research fellow at TNO and a professor in systems engineering in Norway. On the basis of his own experience as a system architect, he developed the so-called CAFCR method (Figure 1), which employs five ‘views’: Customer Objectives, Application, Functional, Conceptual, and Realization.

System - system-architecture--figure-1-cafcr
Figure 1. The CAFCR method.

The method provides the structure for an iterative process in which a chain of questions has to be answered: Who is the customer? What is his application? What is the function of the product in the application? With what concept(s) can this be achieved? Is this concept feasible? What are the constraints? Are there new opportunities? [1]


Muller used the CAFCR method as the foundation for a new training course, called Sysarch (“System architecting”), which was launched around 2000. In 2002, Ger Schoeber (Figure 2) joined as a teacher and he has now been the acting course leader for many years. On the course provider’s site a clear definition is given:

“System architecting is the art and science of designing and building multi-disciplinary systems. The responsibility and the challenge for the system architect is to translate the requirements of the many stakeholders into a system architecture blueprint. He/she will do this based on a solid knowledge of the problem domain, the business context, the human context, the solution domain, technology roadmaps and preceding architectures. The system architect provides the vision, develops the outline for an integral design, keeps the overview and takes care of the design consistency. He/she provides the context for the development activities that will be carried out by large multi-disciplinary teams of specialists.”

System - system-architecture--figure-2-gerschoeber
Figure 2. Ger Schoeber is manager Innovation & Technology at Hotraco and course leader of the “System architecting” training course. He is a board member of INCOSE-NL, the Dutch branch of the International Council on Systems Engineering, and a steering group member of the System Architecture Study Group (SASG).

Three roles

It is clear that technology is important, but it is ill-advised to make a one-track-minded, technology-driven engineer the system architect in a design project. Communication skills and business sense are essential ‘tools’ for a system architect, as well as extensive experience. There is a training course, but system architecting is first and foremost learned in practice, hence a system architect is usually a senior professional.


To further outline the scope, Schoeber defines the three leading roles in a technically complex design project:


In theory, one and the same person can fulfil these three roles, but it is best when three people each assume one role. Not only does this prevent work overload, also the tensions between potentially conflicting interests that are inherent to any complex project are explicitly represented. Each interest has its own representative and the discussions between them can lead to a well-balanced, optimal project result.


From the above it is evident that the ‘duties’ of a system architect are numerous. Among them is requirements engineering, formulating the technical requirements in a ‘smart’ manner: specific, measurable, achievable, relevant and time-bound. This is the basis for any successful design project. Manufacturability is also the architect’s responsibility; this concerns production technologies, materials, cost price, lead time, etc.

Another important aspect of architecting is roadmapping. Choices made regarding the architecture have to be consistent with existing technological and business roadmaps for product (families). On the other hand, these choices can be guiding for new roadmap formulations, so the (future) roadmap always has to be at the back of the architect’s mind.

Best of both worlds

Whereas architecting is a common phrase in the high-tech domain system, other domains, such as civil engineering, work with system engineering. There are overlaps and differences between the two terms, related to the complexity of projects from either the technical, business or organisational perspective. In all cases, the ultimate challenge is the same: delivering a sound technical system that is of value to the company and the market.


In system engineering, the emphasis is often on process and stakeholder management. As a consequence, losing focus on the technical aspects may introduce risks in the final design. On the other hand, in the high-tech domain the main concerns are often technical complexity and time-to-market. This induces a pragmatic way of working in which the careful execution of the project plan receives less attention. According to Ger Schoeber, however, it is possible to merge the system engineering and system architecting approaches and combine the best of both worlds.

V-model vs Agile

The adage ‘best of both worlds’ also applies to the methods and tools used in system architecting [1], such as the above-mentioned CAFCR method. This is best illustrated by looking at two ‘extremes’, the V-model and Agile.

The V-model is a well-structured method, originally devised for hardware-dominated product development (Figure 3). A linear trajectory is followed from the upper left arm of the V (user requirements definition) through various (sub)system development stages to ultimately user testing. A forte of the V-model is that specification and verification are ‘automatically’ linked to one another at every development level, assuring a design that satisfies the requirements. However, this linear progression is a time-consuming procedure, especially if in later stages design problems or last-minute requirement changes necessitate a redesign in a previous stage.

System - system-architecture--figure-3-gr2
Figure 3. The V-model [2]; see the text for further explanation.

Here the Agile method (Figure 4), originating from the domain of software development, comes in with its project ‘sprints’. A sprint is a short design iteration in which part of the functionality is developed, starting with the critical parts of the design, to create a so-called minimum viable product for which feasibility can be demonstrated at an early stage. This reduces the risk of extensive reiterations at later stages and in subsequent sprints new functionality can be added, building upon the proven core design.

System - system-architecture--figure-4-agile-sprint
Figure 4. The sprint-based Agile method; see the text for further explanation.

Now it is the architect’s mission to combine the two development ‘cultures’: the long-term goal orientation of the V-model with the short-term flexibility and development speed of Agile. Schoeber envisions a V-model in which at any given moment in time different parts of a design are each at different stages of their development trajectory: when some parts are still at the concept phase, other parts are already at the detailed design phase. Here the so-called student syndrome, i.e. doing the easy bits first to postpone a difficult assignment, should be avoided, Schoeber warns. It is essential to deal with the critical design challenges first.


Finally, talking about ‘worlds’, there is another cultural dimension at play. The high-tech community in the Netherlands is adept in system architecting, Ger Schoeber states, partly due to the Dutch ‘polder’ mentality, combining pragmatism and innovativity. Other countries/cultures, where for example hierarchy is held in high esteem, are better at process planning, sticking to the plan and delivering what was ordered, but have problems dealing with new insights or developments and adjusting plans. Here lies a real challenge for large multi-site, multinational projects and a new role for the system architect, that of cultural interface within a project team.



[1] R. Zwikker and J. Gunsing, “Merging Process Structure and Design Freedom”, Mikroniek, vol. 55 (2), pp. 5-13, 2015.

High Tech Institute organises the 
'System Architect(ing)' course
3 - 4 times a year. 

Course description