Evaluate to Learn

Architecture evaluation is a process by which we learn the extent to which an architecture is fit for purpose. A common fallacy when designing software architectures the belief that we should check the architecture only once, at the end of a design phase. If the whole architecture isn’t correct, then everything fails and the implementation can’t start. This thinking is wrong, wrong, wrong.

Architectures are never wholly good or wholly bad. Just like we can’t see the entire architecture in a single view, we also can’t evaluate the whole architecture in a single go. It’s possible for a single component to be well designed, or one area of the architecture to be well understood while others are filled with risk. Not everything is required to be fully baked to begin implementation.

One way to use architecture evaluations is as a ceremonial sign-off. In cases where components must strictly meet specific criteria, such sign-offs can be extremely valuable. For example, a sign-off evaluation can avoid costly rework for systems with many integration points or significant hardware needs.

While sign-offs are sometimes important, using evaluations only as a phase gate check is a missed opportunity. The world constantly changes around us. The only way to know whether our architecture still satisfies our stakeholders’ needs is to evaluate it.

During our evaluations we want to learn two things: How good is the architecture? and How is the architecture good? To answer these questions, we’ll use what we know about the architecturally significant requirements (ASRs). The better the architecture satisfies the ASRs, the better the architecture fits its purpose.