After many years of solution architecture work — across industries, technologies, and organisational contexts — I have come to believe that the difference between good and poor architecture is less about technical knowledge than about a handful of foundational principles applied consistently and with genuine judgment.

Patterns and frameworks are useful references. But they cannot tell you when a microservices architecture is more liability than asset, or when eventual consistency is an acceptable trade-off, or when the right answer is to push back on the requirement rather than architect around it. That requires principles that have been internalised, tested against reality, and refined through experience.

Here are the five principles that guide every solution design engagement at Ergotech.

1. Design for the Operator, Not the Architect

The primary user of a production system is not the person who built it. It is the operations team or engineering team who must maintain it, diagnose it at 2am, and evolve it over years. Architecture that is elegant in design but opaque in operation is not good architecture.

This principle changes specific design decisions. It means preferring explicit over implicit behaviour — configuration that is readable, contracts that are declared, dependencies that are visible. It means designing for observability as a first-class concern, not as a logging afterthought. It means asking, "If I were new to this system and something went wrong, could I understand what was happening?" and designing accordingly.

The temptation to solve operational complexity with sophisticated tooling should be resisted. Every layer of abstraction added for the architect's convenience becomes a debugging surface the operator must understand.

2. Complexity Has a Tax — and Someone Always Pays It

Every increase in system complexity has a cost: higher onboarding time, more failure modes, more cognitive load for the people who maintain it. These costs are often not paid by the person who introduced the complexity. They are paid later, by different people, in the form of incidents, slow delivery, and accumulating technical debt.

This principle demands that architects make the cost of complexity explicit and visible before it is accepted. "We could use an event-driven architecture here" is not a complete statement. "We could use an event-driven architecture here, which will give us these benefits but will require us to handle eventual consistency, manage consumer lag, and own an event schema registry" is closer to honest.

The question is not whether the complexity is justified. The question is whether the people who will pay the tax have consented to it and have the capability to manage it.

3. Security Constraints Are Design Inputs, Not Design Obstacles

In most organisations, security enters the solution design process as a review — something that happens to a design that already exists. This is wrong, and it produces the characteristic outcomes of bolted-on security: compensating controls that add friction, compliance workarounds that create risk, and architecture decisions that cannot easily be reversed.

Treating security constraints as design inputs from the start changes the outcome. When the threat model is done before the architecture is finalised, it can actually shape the architecture. When data classification is a design constraint rather than a label applied retrospectively, data flows are designed to respect it. When identity and access requirements are defined upfront, the integration between systems reflects them.

This is the core of security-by-design — not a checklist, but a disposition that brings security into the design conversation at the earliest possible point.

4. Make Your Assumptions Explicit and Time-Bound

Every architecture is built on assumptions: about traffic volumes, about team capability, about how requirements will evolve, about what the business will prioritise in eighteen months. These assumptions are usually implicit — embedded in decisions without being stated. When they are wrong, the architecture fails in ways that are hard to diagnose because nobody remembered the assumption they were violating.

Good architecture documentation makes assumptions explicit and assigns them a confidence level and a review horizon. "We are assuming this system will serve fewer than 10,000 concurrent users for the next 12 months. If that assumption changes, the session management design will need to be revisited." That is a useful statement. It creates a trigger for review and prevents the assumption from becoming invisible.

  • List your key assumptions when you publish a design document
  • Assign each assumption a confidence level — high, medium, or low
  • Define what evidence would tell you the assumption is wrong
  • Set a review horizon after which the assumption must be validated

5. Architecture Is a Negotiation, Not a Decree

The most technically correct architecture that the organisation cannot execute is worthless. Architecture must account for organisational constraints — team capability, delivery capacity, risk appetite, and political reality — as seriously as it accounts for technical constraints.

This means the architect's role is fundamentally one of facilitation and persuasion, not pronouncement. The best architects I have worked with spend as much time listening as they do designing — understanding what teams can actually build and maintain, where the real risk tolerance lies, and what constraints are fixed versus negotiable.

It also means knowing when to push back — when a requirement, once examined, produces a disproportionate cost in complexity or risk, and needs to be renegotiated rather than accepted as given. The architect who implements whatever the business asks is not providing architecture; they are providing execution. Real architecture includes the judgment to challenge the brief.

Applying the Principles

These principles are not a checklist to be applied at the end of a design process. They are dispositions to be brought into every design conversation, every review, and every trade-off decision. They do not produce the same answer every time — that is the point. Principles applied with judgment produce context-appropriate design. Frameworks applied mechanically produce generic design.

If you would like to discuss solution architecture for a specific challenge your organisation is facing, get in touch.