30 Essential Architecture Principles Every Software Architect Should Follow

Introduction

Srinath, a software architect and Apache Axis2 co‑founder, distilled thirty widely‑accepted architecture principles to help teams resolve design disputes and guide novice architects.

1. Basic Principles

Principle 1

KISS – Keep it simple, stupid. Choose the simplest solution that solves the problem.

Principle 2

YAGNI – You aren’t gonna need it. Build only what is required now; defer the rest.

Principle 3

Crawl, walk, run: first get a working prototype, then improve, then perfect. Use two‑week milestones and iterate in an agile fashion.

Principle 4

Automated testing is the sole path to stable, high‑quality products; design with testability in mind.

Principle 5

Always consider ROI – ensure the effort is justified.

Principle 6

Know your users; balance effort with actual needs (e.g., a CLI may be preferred over a polished DevOps UI).

Principle 7

Design and test features to be as independent as possible to avoid waiting on other components.

Principle 8

Avoid flashy, unused features; focus on what will actually be used.

2. Feature Selection

Principle 9

Embrace MVP – build a minimal viable product, release early, gather feedback, then iterate.

Principle 10

Do as few features as possible; when in doubt, discard or leave an extension point.

Principle 11

Implement only when demand arises, unless it affects core processes.

Principle 12

Have the courage to say no to customers and propose better solutions (recall Henry Ford’s famous quote).

3. Server Design and Concurrency

Principle 13

Understand the full stack – hardware, OS, language – and optimise I/O calls.

Principle 14

Apply Amdahl’s law; avoid shared mutable state, use concurrent structures sparingly, and minimise lock hold time.

Principle 15

In non‑blocking, event‑driven architectures, never block threads or perform heavy I/O inside them.

4. Distributed Systems

Principle 16

Stateless services are inherently scalable; avoid stateful designs.

Principle 17

Strive for exactly‑once message delivery; it’s hard without client‑server coordination, so keep the system lightweight.

Principle 18

Make operations idempotent to support at‑least‑once delivery safely.

Principle 19

Know the CAP theorem; distributed transactions are difficult—prefer compensation patterns over traditional RDBMS transactions.

Principle 20

Distributed consistency does not scale well; ideal clusters are limited to about eight nodes.

Principle 21

Latency and failures are inevitable in distributed environments.

5. User Experience

Principle 22

Understand user goals and expertise: geeks like extension points, developers want examples/scripts, casual users prefer UI.

Principle 23

The best product needs no manual.

Principle 24

When faced with two choices, don’t expose the dilemma as a configuration option; provide a sensible default or automate the decision.

Principle 25

Always set reasonable default values for configurations.

Principle 26

Provide example values for configurations to avoid confusion.

Principle 27

Configuration values must be understandable and directly settable (e.g., ask for max cache memory instead of number of entries).

Principle 28

Throw an error on unknown configuration values; never silently ignore them.

6. Tough Problems

Principle 29

Don’t assume a new programming language will magically simplify development; mastering a new language is hard.

Principle 30

Avoid overly complex drag‑and‑drop UIs unless you have a massive team; aim for orthogonal components (security, messaging, registry, validation, analytics) but accept early duplication as a practical reality.

Conclusion

An architect should act like a gardener—pruning, guiding, and facilitating discussion rather than dictating design. A well‑curated principle list serves as an anchor for team conversations and a learning path for new architects.