Skip to main content

Über dieses Buch

Thorough and continuous architecting is the key to overall success in software engineering, and architecture evaluation is a crucial part of it. This book presents a pragmatic architecture evaluation approach and insights gained from its application in more than 75 projects with industrial customers in the past decade. It presents context factors, empirical data, and example cases, as well as lessons learned on mitigating the risk of change through architecture evaluation.

By providing comprehensive answers to more than 100 typical questions and discussing more than 60 frequent mistakes and lessons learned, the book allows readers to not only learn how to conduct architecture evaluations and interpret its results, but also to become aware of risks such as false conclusions, manipulating data, and unsound lines of argument. It equips readers to become confident in assessing quantitative measurement results and recognize when it is better to rely on qualitative expertise.

The target readership includes both practitioners and researchers. By demonstrating its impact and providing clear guidelines, data, and examples, it encourages practitioners to conduct architecture evaluations. At the same time, it offers researchers insights into industrial architecture evaluations, which serve as the basis for guiding research in this area and will inspire future research directions.



What Is the Point of Architecture Evaluation?


Chapter 1. Why Architecture Evaluation?

Architecture evaluation is a valuable, useful, and worthwhile instrument for managing risks in software engineering. It provides confidence for decision-making at any time in the lifecycle of a software system. This chapter motivates architecture evaluation by explaining its role and its initiators, and by pointing out its benefits. Architecture evaluation requires investments, but saves time and money (if done properly) by preventing wrong or inadequate decisions.
Jens Knodel, Matthias Naab

Chapter 2. What Is the Background of Architecture?

We will sketch the big picture of architecting in this chapter—it is far more than just a phase for modeling boxes and lines between requirements and implementation. Today’s complex software systems require continuous architecting over the whole lifecycle of the software system. We will place particular emphasis on industrial practice, where architecting can never be done in the ideal way but where one has to continuously make deliberate tradeoffs.
Jens Knodel, Matthias Naab

Chapter 3. What Is Architecture Evaluation?

In this chapter, we will present what architecture evaluation is and what it consists of. We will break down the overall method of architecture evaluation into five clearly delineated checks: (1) checking the integrity of the drivers, (2) checking the solution adequacy of an architecture, (3) checking the architecture documentation quality, (4) checking the compliance of the implementation with the architecture, and (5) checking the code quality in general. We will introduce confidence levels as a response to the risk-driven idea of architecture evaluation: we only want to invest as much as needed to gain enough confidence. We will show how evaluation results can be interpreted, aggregated, and represented to senior management by mapping them to a color-coded rating scale.
Jens Knodel, Matthias Naab

Chapter 4. How to Perform an Architecture Evaluation?

There are typical indicators that an architecture evaluation would be beneficial. Architecture evaluation is typically conducted as a project, answering specifically formulated evaluation goals. We will show the big picture of how an evaluation project can be set up and structured, including which stakeholders to involve and how to manage their expectations. We will offer support for estimating the effort for an architecture evaluation and the actual project management. Finally, we will share experiences on the interpretation of evaluation results and describe how to structure a concluding management presentation that accurately conveys the evaluation results and presents recommendations.
Jens Knodel, Matthias Naab

How to Evaluate Architectures Effectively and Efficiently?


Chapter 5. How to Perform the Driver Integrity Check (DIC)?

The goal of the Driver Integrity Check (DIC) is to get confidence that an architecture is built based on a set of architecture drivers that is agreed upon among the stakeholders. We will show how to work with stakeholders and how to reveal unclear architecture drivers or those on which no agreement exists. Architecture drivers are expressed using the well-known architecture scenarios. The activity is based on classical requirements engineering aimed at compensating for not elicited requirements and aggregating a large set of requirements into a manageable set for an architecture evaluation.
Jens Knodel, Matthias Naab

Chapter 6. How to Perform the Solution Adequacy Check (SAC)?

The main goal of the Solution Adequacy Check (SAC) is to check whether the architecture solutions at hand are adequate for the architecture drivers identified and whether there is enough confidence in the adequacy. We present a pragmatic workshop-based approach that is based on ideas of ATAM. We provide guidance for the documentation of evaluation results, such as the discussed architecture decisions and how they impact the adequacy of the overall solution. We also provide concrete templates and examples and show how evaluation results and specific findings can be rated and represented.
Jens Knodel, Matthias Naab

Chapter 7. How to Perform the Documentation Quality Check (DQC)?

he main goal of the Documentation Quality Check (DQC) is to check how adequate the architecture documentation is for its audience and purposes. The evaluation checks both the content and the representation of the architecture documentation. Thinking from the perspective of the audience and considering the purposes of the documentation helps to rate the adequacy of the documentation. In addition, principles of good documentation, such as structure, uniformity, or traceability, can be checked. These principles are determined by the mental capabilities of the readers and can be used across domains and system types.
Jens Knodel, Matthias Naab

Chapter 8. How to Perform the Architecture Compliance Check (ACC)?

The main goal of the Architecture Compliance Check (ACC) is to check whether the implementation is consistent with the architecture as intended: only then do the architectural solutions provide any value. Nevertheless, implementation often drifts away from the intended architecture and in particular from the one that was documented. We will show typical architectural solutions that are well suited to being checked for compliance. Compliance checking has to deal with large amounts of code and thus benefits from automation with tools. Not all violations of architecture concepts have the same weight: we provide guidance for the interpretation of compliance checking results.
Jens Knodel, Matthias Naab

Chapter 9. How to Perform the Code Quality Check (CQC)?

The main goal of the Code Quality Check (CQC) is to gather data about the source code base. As such, the CQC is not a direct part of the architecture evaluation.
Jens Knodel, Matthias Naab

How to Apply Architecture Evaluation in Practice?


Chapter 10. What Are Example Cases of Architecture Evaluation?

An architecture evaluation approach can be illustrated best with examples in which the approach was applied. We report on four real but anonymized architecture evaluation projects with industrial customers. We will show how critical decisions about the future of a software system were supported, how architecture evaluation was applied to identify risks, and how architecture evaluation supported the selection of a foundational technology. We will share experiences with the application of our checks and show the results as they were presented in the management presentation. We will then summarize lessons learned from more than 75 architecture evaluation projects on architecting in general, on maintainability, and on metrics, and briefly outline how our evaluation approach evolved over time.
Jens Knodel, Matthias Naab

Chapter 11. How to Engage Management in Architecture Evaluation?

Management support is crucial for starting and conducting architecture evaluations, and even more important for exploiting the results to improve the software system. This chapter presents data, numbers, and insights gained from our project retrospective on points that are typically important to management: effort, duration, benefits, scaling factors, and improvement actions.
Jens Knodel, Matthias Naab

Chapter 12. How to Acquire Architecture Evaluation Skills?

Acquiring architecture evaluation skills is crucial for successful architecture evaluation projects. While this book provides answers to many questions in the area of architecture evaluation and introduces a comprehensive methodology, very good architecture evaluation skills will only come with practical experience. We will point out in the following how skills for architecture evaluation complement general architecting skills. A great source of skills is to explore a large number of software systems and their architectures in great detail and to try to follow these software systems and their maintenance over their entire lifetime. Accompanying experienced evaluators is a great source of learning: observing how they work with stakeholders, thoroughly investigating the technical solutions, and presenting the results to management at the right level of abstraction.
Jens Knodel, Matthias Naab

Chapter 13. How to Start and Institutionalize Architecture Evaluation?

Here, we will offer guidance on how to get started with architecture evaluation and how to institutionalize it in one’s own company. There are many good opportunities for doing a first and beneficial architecture evaluation—new development, modernization of a system, or selection of new technologies. We will share best practices regarding how to have a successful start and how this success can be sustained. Finally, we will look at more sophisticated architecture evaluation methods and how the discipline can be further improved with even more dedicated guidance or a higher degree of automation, for example by integrating repeated compliance checks into the build process.
Jens Knodel, Matthias Naab

Chapter 14. What Are the Key Takeaways of Architecture Evaluation?

Thorough and continuous architecting is the key to overall success in software engineering, and architecture evaluation is one crucial part of architecting.
Jens Knodel, Matthias Naab


Weitere Informationen

Premium Partner

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.



Best Practices für die Mitarbeiter-Partizipation in der Produktentwicklung

Unternehmen haben das Innovationspotenzial der eigenen Mitarbeiter auch außerhalb der F&E-Abteilung erkannt. Viele Initiativen zur Partizipation scheitern in der Praxis jedoch häufig. Lesen Sie hier  - basierend auf einer qualitativ-explorativen Expertenstudie - mehr über die wesentlichen Problemfelder der mitarbeiterzentrierten Produktentwicklung und profitieren Sie von konkreten Handlungsempfehlungen aus der Praxis.
Jetzt gratis downloaden!