International Journal of Wireless and Mobile Computing

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Knodel J., Naab M.

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

Knodel J., Naab M.

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.

Knodel J., Naab M.

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.

Basili V., Trendowicz A., Kowalczyk M., Heidrich J., Seaman C., Münch J., Rombach D.

This chapter summarizes the origins and benefits of the GQM+Strategies approach. We discuss the challenges business organizations face with regard to alignment and briefly explain how GQM+Strategies helps to address these challenges by describing the fundamentals of the approach as well as its core components. Furthermore, we provide insights into how GQM+Strategies evolved from and uses the Goal–Question–Metrics (GQM) approach, which is a well-known measurement approach in the software development domain, and we discuss the benefits of this evolution.