Reference architectures for product families
Within many companies, complexity is increasing due to the growing variety of products and the increasing demand for customer-specific products, next to the use of more complex technologies and the integration into more and more complex product environments. The increase of complexity ripples through the entire organization and it negatively affects all processes, at multiple levels (e.g. delays in the design of products, complicated manufacturing processes, extensive management of the organization, expensive service activities, etc.). A Reference Architecture helps to deal with this complexity challenge, as it provides structure in product development and guidance to the organization.
In general, a Reference Architecture is “an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions” [2]. Furthermore, it “shall provide guidance to facilitate the effective creation of products, products lines, and product portfolios” [5]. The purpose of a reference architecture is fourfold:
to provide a common language for the various stakeholders;
to provide rationale and consistency of implementation of technology to solve stakeholder needs;
to support the validation of solutions against proven Reference Architectures;
to encourage adherence to common standards, specifications, and patterns.
In short, a Reference Architecture captures the essence of existing architectures, and the vision of future needs.
The recent ESI research on Reference Architectures has accomplished three major reusable results that have been applied and validated in the respective industrial contexts:
a generic structure of a Reference Architecture;
a Reference Architecture for introducing security and privacy;
a method to create a Reference Architecture for high tech systems.
In order to facilitate the effective creation of products, products lines, and product portfolios, a reference architecture must closely reflect the organization’s values and the strategic concerns governing the organization’s products. It should also capture the domain fundamentals underlying these products, together with the key design space elements, and reasoning lines supporting trade space analysis for possible solutions.
The ArchWay project aimed to make a major step towards setting up a reference Electronic/Electrical (E/E) architecture for use with professional vehicles. The purpose of such an E/E reference architecture was to provide guidance for future developments, and to facilitate a shared understanding across multiple product lines, organizations, and disciplines about current architectures and future directions.
An important project result is the generic structure for a reference architecture, building on the definition of the US Department of Defense [1]. Figure 1 shows its elements, their relations, and the context for which the reference architecture is created.
The generic “reasoning methods” of reference architecture are detailed in:
domain fundamentals, providing the core concepts of how to think about possible solutions;
design space, reasoning & trade-offs, showing how to weigh alternatives, and balancing qualities and criteria towards solutions meeting customer value requirements.
This generic structure can be used effectively as a blueprint to determine which elements and relations are needed for a specific reference architecture in a specific context.
The development of a reference architecture to assist solution architects in introducing privacy and security into safe automated systems, was the topic of the EU project Secredas. The reference architecture enables systematic re-use of solution elements to reduce risks of introducing unintended errors and design mistakes. It focuses on the balanced introduction of security and privacy into systems in the health, automotive, and railway domains, while respecting multiple concerns of stakeholders (Figure 2).
The developed reference architecture uses the relevant elements of Figure 1 and consists of:
customer, Business, and Technical aspects relevant to the development of individual solutions;
preferred views to clearly describe solutions for security and privacy concerns;
privacy [3] and security principles to highlight, discuss, and document rationale for decisions;
reasoning methods for stepwise applying principles for specific purposes, e.g., privacy architecting or security auditing.
The powerful reasoning method to systematically design for privacy and security is a major result of the project. The principles to choose from are in fact best practices reflecting the characteristics of security and privacy technologies, see Figure 3.
The provided guidance enables architects from automotive, health, and railway domains to re-use market-ready security and privacy technologies in different business, customer, and technology contexts [4]. Furthermore, using common views greatly facilitates interactions between developers. The privacy and security principles assist in discussions between security and privacy specialists, and architects. And finally, the Customer, Business, and Technical aspect views provide a sound framework to address a large variety of applications.
Want to know more? Go to the ESI demo of the Secredas project.
The Reference Architecture Distilling Method (RADIST) is a structured way of creating a reference architecture for high-tech product (families), driven by market and business values [1].
The benefits of the RADIST method are that:
it provides stepwise the elements of a Reference Architecture (see also Figure 1), starting with the explicit understanding of customer and business values;
it enables a mindset for and insight in the opportunities for reuse and platform development.;
it delivers the baseline for many processes in the business, from roadmapping and portfolio strategy development to implementing new product features.
The RADIST method offers a systematic way of working towards a supported reference architecture. The approach consists of the following steps, see Figure 4:
customer and business values are analyzed as a starting point;
to clarify how customers use a system to create these values, workflows are analyzed:
customer workflows to understand the processes in which the system is used;
system workflows to understand in much more detail how the functions of the systems are used in these customer workflows;
to understand and capture the functionality of the system, a functional system decomposition is created;
based on business drivers and knowledge about existing system designs, a system decomposition is created, defining strategic system components and their functionality, interfaces and properties;
current system realizations (products, modules and their interfaces and dependencies) are confronted with the system decomposition. This serves as a sanity check of the system decompositions, the starting point of creating an architecture roadmap, and the starting point for identifying platform components;
the method includes the linking of the various types of information (the reasoning is indicated by the arrows in Figure 4), as it will improve the understanding of the ‘what’ and the ‘how’ of the systems and products.
Parallel to the consolidation of this knowledge, the creation and usage of a reference architecture stimulates ‘system thinking’ in the organization, especially of the involved architects and engineers.
White paper PaloAlto project
Richard Doornbos, Jelena Marincic, Alexandr Vasenev, Jacco Wesselius
[1] Richard Doornbos, Jelena Marincic, Alexandr Vasenev, Jacco Wesselius, ‘Reference Architecting – A methodology for distilling and documenting a reference architecture for complex high-tech systems’, white paper PaloAlto project, ESI, 2021.
[2] US Department of Defense, Office of the Chief Information Officer (DoD/CIO), Reference Architecture Description, Jun 2010, (last accessed 11-12-2020)
[3] Riva, G. M., Vasenev, A., & Zannone, N. (2020, August). SoK: Engineering privacy-aware high-tech systems. In Proceedings of the 15th International Conference on Availability, Reliability and Security (pp. 1-10).
[4] Marko, N., Vasenev, A., & Striecks, C. (2020, September). Collecting and Classifying Security and Privacy Design Patterns for Connected Vehicles: SECREDAS Approach. In International Conference on Computer Safety, Reliability, and Security (pp. 36-53). Springer, Cham.
[5] Robert Cloutier, Gerrit Muller, Dinesh Verma, Roshanak Nilchiani, Eirik Hole, and Mary Bone, The Concept of Reference Architectures, Systems Engineering Vol. 13, No. 1, pp. 14-27, 2010, https://onlinelibrary.wiley.com/doi/abs/10.1002/sys.20129.
[6] G. J. Muller, CAFCR: A Multi-view Method for Embedded Systems Architecting. Balancing Genericity and Specificity, 2004.