30 Architectural Principles for Software Architects

The author, Srinath, a scientist, software architect, and co‑founder of Apache Axis2, shares thirty architectural principles he has distilled from extensive experience in distributed systems.

Basic Principles

Principle 1: KISS (Keep It Simple, Stupid) – solve problems with the simplest possible solution.

Principle 2: YAGNI (You Aren’t Gonna Need It) – implement features only when they are truly needed.

Principle 3: Crawl, Walk, Run – first get a working version, then iteratively improve it.

Principle 4: Automated testing is the only way to build stable, high‑quality products.

Principle 5: Always consider ROI (Return on Investment) when deciding what to build.

Principle 6: Understand your users and balance work accordingly; avoid building UI for users who prefer CLI.

Principle 7: Design and test features to be as independent as possible.

Principle 8: Avoid unnecessary flashy designs that are never used.

Feature Selection

Principle 9: Embrace MVP (Minimum Viable Product) – release a small set of core scenarios, gather feedback, then iterate.

Principle 10: Implement as few features as possible; prune unnecessary ones.

Principle 11: Defer work until it is actually required, unless it impacts core processes.

Principle 12: Courageously say “no” to customers when a better solution exists; guide them like Henry Ford’s famous quote.

Server Design and Concurrency

Principle 13: Understand the full stack – hardware, OS, language – and minimize I/O calls.

Principle 14: Apply Amdahl’s Law; use concurrent data structures only when necessary and keep lock hold times minimal.

Principle 15: In non‑blocking, event‑driven architectures, never block threads or perform blocking I/O.

Distributed Systems

Principle 16: Stateless systems are scalable and straightforward.

Principle 17: Strive for exactly‑once delivery, though it is hard; aim for lightweight designs.

Principle 18: Make operations as idempotent as possible to aid recovery.

Principle 19: Know the CAP theorem; use compensation mechanisms instead of distributed transactions when possible.

Principle 20: Distributed consistency does not scale; keep node count modest (ideally ≤ 8).

Principle 21: Latency and failures are inevitable in distributed systems.

User Experience

Principle 22: Understand user types (novice, expert, occasional) and tailor interfaces accordingly.

Principle 23: The best product requires no manual.

Principle 24: When faced with a binary decision, provide a sensible default rather than exposing the choice to users.

Principle 25: Always set reasonable default values for configurations.

Principle 26: Provide example values for configuration options.

Principle 27: Configuration values must be understandable and directly editable by users.

Principle 28: Reject unknown configuration values with explicit errors.

Difficult Issues

Principle 29: Switching languages for simplicity is rarely beneficial; avoid unnecessary language changes.

Principle 30: Complex drag‑and‑drop UIs are hard to implement; only attempt them with a large, dedicated team.

Summary

Architects should act as gardeners—pruning, guiding, and facilitating discussions rather than dictating designs—using this widely‑accepted principle list as an anchor for decision‑making and as a learning path for junior architects.