Trade-offs, Decisions, and How to Break In

Lesson 2 ended with the requirements clear. Now the architect faces the real work, and the single most important idea in the whole discipline: there is no best architecture. There are only trade-offs.

Beginners look for the "right" design, as if architecture were a puzzle with one correct answer. It is not. Every meaningful architectural choice improves some qualities at the expense of others. You do not get more of everything; you decide what to prioritize and what to sacrifice, for this specific context.

A few classic tensions make it concrete:

• Performance vs cost. Faster usually means more infrastructure, caching, redundancy, all of which cost money.
• Security vs usability. More authentication steps and stricter controls protect the system and add friction for users.
• Consistency vs availability. In distributed systems, guaranteeing everyone sees the same data instantly can conflict with staying available during failures.
• Flexibility vs simplicity. A highly configurable, future-proof design is more complex to build, understand, and operate.
• Time-to-market vs robustness. Shipping fast often means cutting corners you must later repay.

The architect's job is not to escape these tensions, which is impossible, but to resolve them deliberately, in favour of the qualities that matter most for this system. For a bank, lean toward security and consistency even at the cost of speed and convenience. For a startup chasing a market, lean toward time-to-market even at the cost of robustness.

This is why the same architect designs different systems differently, and why "it depends" is not a dodge but the honest, correct answer. The whole craft is knowing what it depends on.

If trade-offs are the essence, the architect needs a disciplined way to make them, not gut feel. The idea, formalized in methods like the ATAM (Architecture Tradeoff Analysis Method) from Carnegie Mellon's Software Engineering Institute, is to evaluate candidate designs explicitly against the quality attributes that matter.

You do not need the full formal method to use its logic. The core move is a structured comparison:

1. List the quality attributes that matter here, ranked, from Lesson 2's requirements. (Say: security, then reliability, then cost, then performance.)
2. Lay out the candidate designs, two or three real options.
3. Score each design against each attribute, honestly, noting where it helps and where it hurts.
4. Find the sensitivity and trade-off points, the decisions where one attribute is bought at another's expense, and check them against your ranking.
5. Choose the design that best serves the top-ranked attributes, accepting its costs on the lower ones with eyes open.

Cloud vendors ship the same thinking as guidance. The AWS Well-Architected Framework, for instance, is built on pillars, operational excellence, security, reliability, performance efficiency, cost optimization (and sustainability), and states plainly that you make trade-offs between pillars based on your business context: optimize reliability at higher cost for a mission-critical system, or optimize cost at some reliability risk for a development environment.

The point of any such method is the same: make the trade-offs visible and deliberate instead of accidental. A design chosen because its trade-offs were consciously weighed against ranked priorities is defensible. A design chosen because it was familiar, and whose sacrifices nobody noticed until production, is how projects fail while everyone is being reasonable.

One trade-off is so common it deserves its own treatment: for almost any capability, should you build it custom or buy an existing product or service? Architects make this call constantly, and it is where the most money is won or lost.

The naive comparison, "license fee versus developer salaries," gets it badly wrong, because it compares the wrong numbers. The right lens is total cost of ownership (TCO): every cost across the whole life of the solution, not just to acquire it.

• Build TCO hides far beyond the initial development. You own it forever: maintenance, bug fixes, security patching, hosting, and the opportunity cost of engineers doing this instead of your actual product. A widely cited rule of thumb is that roughly 80 percent of a software's total cost comes after the initial launch, and industry estimates put ongoing maintenance around 15 to 20 percent of the original build cost every year.
• Buy TCO also hides: implementation and integration effort, per-seat or consumption charges that grow with you, renewal increases, and the risk of being locked into a vendor.

The heuristic architects use is strategic, not just financial:

• Buy what is a solved, commodity problem and not your differentiator. You should not build your own email delivery, payment processing, or authentication, others do it better, cheaper, and it is not why customers choose you.
• Build what is genuinely core to your competitive advantage, the thing you do that no one else does, where an off-the-shelf product would force you to be generic.

The framing to carry: do not build what you can buy unless building is a strategic advantage, and always compare on total lifetime cost, because both paths are routinely underestimated, often by a factor of two to three. Getting this one decision right can matter more than every other architectural choice combined.

An architect's decisions are only as good as the organization's ability to remember why they were made. Six months later, a new engineer looks at a choice, sees only the what, thinks it is obviously wrong, and either wastes weeks re-litigating it or "fixes" it and reintroduces the exact problem it was avoiding.

The tool that prevents this is the Architecture Decision Record (ADR): a short document capturing a single significant decision, with its context and consequences. Many architects consider it the most valuable artifact they produce, because it records the reasoning, not just the outcome.

A good ADR is deliberately small and has a fixed shape:

ADR-014: Use polling instead of an event stream for order updates

Context:  Customers need order status "within a couple of minutes."
          Existing order system updates in 15-min batches.
          Fixed budget; team knows Platform A, not streaming.
Decision: Add a lightweight polling layer over the existing system.
Status:   Accepted
Consequences:
  + Meets the real requirement cheaply, on the known platform, on time.
  - Not true real-time; if sub-second updates are later required,
    this must be revisited (would need the event-stream option).

Why this format earns its keep:

• It records the why. The context and consequences explain the reasoning, so future teams understand the decision instead of guessing.
• It is honest about costs. Good ADRs state what the decision gives up, so nobody is surprised later, and the revisit condition is explicit.
• It is a trail. A sequence of ADRs is the architecture's memory, invaluable when people leave, which they do.

The discipline generalizes past architecture: decisions without recorded rationale are decisions the organization is doomed to make again. Writing the why down is one of the highest-leverage habits an aspiring architect can build, and it can start in any role today.

A design that only the architect understands has failed, because the architect does not build it. The design must be legible to executives who fund it, engineers who build it, and operators who run it, three audiences with completely different needs. Trying to serve all of them with one diagram serves none.

The technique that solves this is communicating at multiple levels of detail, and the clearest modern approach is the C4 model (from Simon Brown). C4 is a set of hierarchical diagrams at four zoom levels, each for a different audience:

• Context: the system as a single box, and who and what it talks to. For everyone, including non-technical stakeholders. "Here is the system and the world around it."
• Containers: the major deployable pieces, the web app, the API, the database, the message queue. For technical stakeholders who need the high-level structure.
• Components: inside one container, the major building blocks. For developers working on that part.
• Code: the lowest level, rarely drawn by hand. For deep implementation detail when needed.

The insight is zoom: start wide for the audience that needs the big picture, and drill in only as far as each audience requires. An executive should never see a component diagram; a developer building the API needs more than the context box. (An older but related idea, the 4+1 view model, similarly describes a system through several complementary views rather than one.)

The general principle for an architect: match the level of detail to the audience. The same architecture is many documents, a context diagram for the steering committee, container and component views for the build team, ADRs for the decision trail. Communication is not an afterthought to the design; for an architect, it is a large part of the job, because an architecture that is not understood is not adopted.

Tie the whole cursus together on one realistic choice. A growing company's single application is straining, and leadership asks the architect: "should we move to microservices?"

1. Requirements and constraints (Lesson 2) first. The real driver is that two teams keep blocking each other in one codebase, and one module needs to scale independently. The constraints: a small team, a tight budget, limited operational maturity.
2. Frame it as a trade-off, not a trend. Microservices buy independent deployment and scaling, and cost a large jump in operational complexity, distributed-system difficulty, and infrastructure. That complexity is precisely what a small, operationally immature team is least able to absorb.
3. Consider options, not a binary. Full microservices; a modular monolith (clear internal boundaries, single deployment); or extracting only the one module that needs independent scaling.
4. Analyze against ranked attributes. Top priorities here are team velocity and manageable operations, not maximal scalability. Full microservices scores worst on operational simplicity, the thing this team most needs.
5. Decide for fit, and record it. Recommend the modular monolith now, plus extracting the single high-scale module, deferring full microservices until the team and load justify it. Write an ADR capturing the context, the decision, and the explicit revisit condition ("reconsider when we have more than N teams or dedicated platform staff").
6. Communicate it. A context diagram and the trade-off summary for leadership; container/component views and the ADR for the engineers.

Every skill in the cursus appears: extract the real requirements, treat the choice as a trade-off against ranked qualities, resist the fashionable answer, choose for fit, record the why, and communicate to each audience. That loop, not any particular technology, is what a solution architect actually does.

Assemble the discipline, and the route into it.

The unifying insight: a solution architect is a professional decision-maker under constraints. The value is not knowing the most technologies; it is choosing well among them for a specific context, and making that choice legible and defensible. "It depends" is the beginning of the answer, and the craft is knowing exactly what it depends on and how to weigh it.

For a career switcher, the path is concrete and mostly grown, not jumped:

• Build breadth from an engineering base. Deliberately learn across databases, integration, cloud, and security, so you can reason about whole systems, not one layer.
• Practice the architect's outputs now, in your current role. Write an ADR for a decision your team makes. Draw a context diagram of a system you know. Do a build-vs-buy analysis on TCO. These are portfolio pieces and skill-builders at once.
• Get close to the business and to trade-offs. Volunteer for the design discussions, sit with stakeholders, learn to translate. The technical part you may already have; the judgment and communication are what you are building.
• Show reasoning, not just knowledge. In interviews, the signal is not naming technologies, it is how you weigh options, surface trade-offs, and justify a choice for a context, exactly the thinking this cursus taught.

Solution architecture rewards breadth, judgment, communication, and the humility to choose fit over fashion, all learnable, and all buildable starting from where you are.

From ranked requirements the architect generates options, analyzes their trade-offs against the top quality attributes including build-versus-buy on total cost of ownership, chooses the best-fitting design, records the why in an ADR, and communicates it at the right level to each audience.