Why Maintainability Should Be the Core Goal of Software Architecture

Evaluating Architecture Objectively

Assessing whether an architecture is good is highly subjective; without clear standards, discussions devolve into personal opinions about performance, security, scalability, and cost.

The lack of a unified metric makes it impossible to reach consensus, and overly detailed scoring systems become ineffective.

Therefore, the author suggests using the extent to which an architecture fulfills the architect's design goals as the evaluation standard: if the system meets its intended objectives, the architecture can be considered good.

Setting Realistic Goals

Different systems have different primary goals. Critical systems like missile launch controls require absolute stability and rapid response, while everyday software often compromises on cost and perfection, leading to the common "cheaper, acceptable" approach.

Given budget constraints, striving for the highest level of performance or reliability is often unrealistic; instead, maintainability becomes the most valuable attribute.

Why Maintainability Matters

The author shares personal experience maintaining a decade‑old logistics system built with multiple languages, illustrating how fixing one bug can introduce another and how maintenance can dominate project effort.

Typical development cycles involve initial rapid development followed by long‑term maintenance by less experienced staff, especially in outsourced or project‑based teams.

Because software can be continuously modified, embracing change is essential, and maintainability must be prioritized to handle evolving requirements.

Design Choices for Maintainability

Choosing appropriate technologies—such as using an object‑oriented language like C# instead of low‑level C—helps support maintainability.

Design patterns are described as "lubricants" that address local architectural shortcomings; they should be applied only when necessary, not as default solutions.

Module Division

Effective module division balances neatness and flexibility. Large modules (e.g., UI, BLL, DAL) provide structure but can limit flexibility, while smaller modules (classes, methods) allow adaptability.

Good module division aids staffing, scheduling, and debugging, whereas poor division leads to chaotic codebases.

Beyond Code

Documentation, project management processes, and team expertise also impact architecture quality. The ultimate purpose of architecture is to simplify code and let developers focus on business logic.

A well‑designed architecture should make each developer a replaceable "screw" that keeps the system healthy and maintainable.