Architecting in the Automotive Domain: Descriptive vs Prescriptive Architecture

Abstract

To investigate the new requirements and challenges of architecting often safety critical software in the automotive domain, we have performed two case studies on Volvo Car Group and Volvo Group Truck Technology. Our findings suggest that automotive software architects produce two different architectures (or views) of the same system. The first one is a high-level descriptive architecture, mainly documenting system design decisions and describing principles and guidelines that should govern the overall system. The second architecture is the working architecture, defining the actual blueprint for the implementation teams and being used in their daily work. The working architecture is characterized by high complexity and considerably lower readability than the high-level architecture.Unfortunately, the team responsible for the high-level architecture tends to get isolated from the rest of the development organization, with few communications except regarding the working architecture. This creates tensions within the organizations, suboptimal design of the communication matrix and limited usage of the high-level architecture in the development teams. To adapt to the current pace of software development and rapidly growing software systems new ways of working are required, both on technical and on an organizational level.

Boundary objects and their use in agile systems engineering

“…Selic confirms modeling languages that produce executable models as a promising enabler for agile documentation . In the automotive domain, the quality of prescriptive models is high, as developers see the direct impact on the implementation and keep them up to date …”

Boundary objects in Agile practices

“…Selic mentioned that indeed, modeling languages that produce executable models are a promising approach for agile documentation [32]. Developers using prescriptive architecture models in the automotive domain keep them up to date as there is a direct impact on the implementation [9]. However, descriptive artifacts are important, e.g., to provide a "big picture" and support decisions, to capture variability, and as documentation for customers and authorities.…”

“…In the focus group sessions in Companies E and F, several participants stressed the usefulness of the distinction between boundary objects Part. Implications/Relation to Challenges (RQ2) [10,17,18,26,30] Artifacts (RQ1) [9,25,27,28,32] F1: Artifacts are either important to support systemlevel thinking in an organization or are used inside a team. I1: Tool solutions should allow for flexibility with the definition of important artifacts and processes to create, update, and use them.…”

“…Guidelines [2,9,15,23,30] G1: Involve stakeholders from different areas to identify what artifacts are boundary objects and locally relevant artifacts.…”

“…Establish traceability to boundary objects. 2,7,8,9 I10: Practitioners trying to align different groups in the organization (Ch1) should focus on traceability to boundary objects. Researchers can focus on increasing the reusability of artifacts to alleviate the maintenance effort.…”