We recommend leveraging the utility tree technique from the architecture tradeoff analysis method, or ATAM.15 Documenting architecture scenarios that illustrate quality attribute requirements is a key aspect of this technique. 15. Software Engineering Institute, Architecture Tradeoff Analysis Method Collection.

In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities—primarily, but not only,

Implement feedback loops, which enable us to iterate through the software development life cycle and understand the impact of architectural decisions. Feedback loops are required so that the team can react quickly to developments in requirements and any unforeseen impact of architectural decisions. In today’s rapid development cycles, we need to be

Focus on quality attributes, which represent the key cross-cutting requirements that a good architecture should address.

For example, enterprise architecture boards make far fewer decisions than product-level governance boards. Note that the scope and significance of architectural decisions also increase with scale. However, most decisions that can impact an architecture are driven on the ground by development teams. The closer you get to implementation, the more

Consequently, we must design our systems with recovery from security incidents in our mind and must think about preventing the incidents in the first place. We discuss system resilience in Chapter 7, but from a security perspective, an important part of ensuring resilience is to work closely with the security specialists and SOC personnel while

Know your technical debt, the understanding and management of which is key for a sustainable architecture. Lack of awareness of technical debt will eventually result in a software product that cannot respond to new feature demands in a cost-effective manner.

A simple but good example for such an architectural principle is “Buy before build.” It has the following characteristics that make a good principle: Clear: Principles should be like marketing slogans—easy to understand and remember. Provides guidance for decisions: When making a decision, you can easily look to the principle for guidance. In this

Guidelines: In reality, the probability of development teams compromising the architecture is greatly reduced if they are given clear guidelines to adhere to.