Skip to content
Software Architecture Guide

Common Architect Mistakes

Explanation

Section titled “Explanation”

Some architect mistakes come up again and again. Eoin Woods collected ten of them in a list. You can use it as a checklist to review your own work. Each item below comes with a way to avoid it.

Scoping woes. The list opens here. Projects grow beyond their original purpose. Assumptions also go unchallenged. One example is the belief that security needs nothing beyond a simple login. The remedy is to question each assumption and ask whether it is really true.

A narrow stakeholder net. A stakeholder is anyone with an interest in the system (see the article Stakeholder). The list warns against not casting the net widely enough. The remedy is to look for stakeholders on purpose (see Stakeholder Identification).

Only functions, no quality attributes. Functions say what the system does. Quality attributes say how well it does it, such as how fast or how secure it is (see Quality Attribute). The list warns against focusing only on functions. A second list of twelve pitfalls agrees: don’t let functional requirements drive the architecture.

Box-and-line diagrams. The list warns against describing a system only with boxes and lines. It also warns against forgetting that the system must actually be built. The remedy is to describe the system in enough detail that a team can build it.

Vague platform, unchecked performance. The list asks for precision about the specific versions and configurations of each part of the platform. It also warns against assuming performance without verifying it. The remedy is to name versions exactly and check performance claims.

Do-it-yourself security. Architects tend to think they can build clever security technology quickly. They are usually wrong. The remedy is to prefer established solutions.

No disaster recovery and no backout plan. The list names both as mistakes. The remedy is to plan for them from the start.

Example

Section titled “Example”

A team plans an online booking tool. The brief says security means “a simple login.” The architect asks whether that is really true and finds that payment data is involved. The architect also asks who else cares: support staff, finance and operations. The team writes down exact platform versions, tests expected load early, and picks a proven login product instead of building one. It also writes a recovery plan and a plan for rolling back a failed release.

Trade-offs

Section titled “Trade-offs”

The verified material covers only part of the topic: ten items in one list and one supporting list of twelve pitfalls. It is not a complete catalog. A checklist also cannot replace judgment. Preferring established security solutions is a general rule, not a rule for every case. Use the list to prompt questions, not to prove a design is sound.

Checks

Section titled “Checks”
  • Assumptions about scope and security needs, such as ‘only a simple login’, are written down and have been challenged.
  • The document does not describe security as home-built technology when established solutions exist.
  • Quality attributes are described explicitly and not only functions.
  • Platform parts are named with specific versions and configurations.
  • A disaster recovery plan and a backout plan exist.
Section titled “Related”

Sources

Section titled “Sources”