Photo by Riho Kitagawa on Unsplash

The report had been running longer than anyone currently responsible for it. It wasn’t sophisticated: a few pages, a handful of filters, and a set of numbers that a team opened every week to track progress against a defined target. Nobody thought of it as architecture. People thought of it the way they think of a light switch: it was there, it worked, and the question of how it worked had never needed asking.

Then one of the data sources beneath it was replaced. The migration was planned, approved, overdue, and appropriate. The new source was better suited to its intended purpose, but it did not preserve the structure or historical coverage of its predecessor. The original was gone, and the replacement could support only part of what the report had been designed to show.

That distinction mattered, because the report wasn’t entirely broken, and the information that remained wasn’t necessarily wrong. It simply no longer represented the complete picture its users had come to expect. Some measures could still be supported, while others depended on information that could no longer be reconstructed. A report designed to measure progress against an established reference point could now offer only a partial view.

That left three options, each with a respectable principle standing behind it, and none without consequences.

The first was to rebuild the report properly, ensuring that every number was complete, accurate, and consistent with its original meaning. That would have been my preference, and it reflected principles I care about a great deal. It also wasn’t available. We could build something new, but we could not reconstruct information we no longer possessed.

The second was to retire the report until a replacement could be developed. A new version was already being discussed, and removing the existing one would eliminate the possibility of someone relying on numbers we could no longer fully substantiate. On paper, that was a clean and defensible answer. In practice, the team still needed to track its progress, and removing the report would not remove that obligation. Weeks without visibility would not pause the target; they would only delay the moment anyone noticed the team was falling behind it. More likely, someone would reconstruct whatever they could in a spreadsheet, using whatever information they could export, without the benefit of a centrally maintained explanation of what had changed or which figures were no longer comparable. The risk would not disappear. It would simply move somewhere less visible, less controlled, and considerably harder to govern.

Completeness could win the argument while losing the outcome, because the decision would simply transfer the problem to someone with fewer tools to recognize or manage it.

The third option was to preserve the portions of the report that remained functional, while making its limitations explicit. Keep the information that could still be supported, and place a visible warning at the top identifying what could no longer be reproduced, why the discrepancy existed, and which conclusions the remaining information could no longer safely support. The report would remain imperfect, and some of its previous utility would be lost, but its limitations would be visible to the people relying on it.

I chose the third option. It was neither the cleanest solution nor the most complete. Of the consequences available to me, it was the one I was most prepared to own.

I have been asked, more than once and in more than one form, what my architectural priorities are. This essay is my attempt at an honest answer, and the answer begins with that report, because on that day a principle I care about took second place, and I was the one who put it there.

The List You Would Expect

Ask an architect for their priorities and you will usually get a list. Security, reliability, maintainability, performance, cost, separation of concerns, in some order, with some conviction.

I have one too, roughly, and I could recite it on demand.

I have also argued, not long ago, that architectures publish their principles but almost never publish their order, because writing down which principle loses is a public commitment about what comes second. So I owe you an order. That was the plan for this essay.

The trouble is that a ranked list of qualities fails at exactly the moment it is needed.

Principles rarely collide in the abstract. They collide inside a specific system, under a specific deadline, with specific people on the other end of the outcome. A list that says security always outranks reliability is false the first time a security control makes a system so difficult to use that the work moves outside it entirely. A list that says it depends is true, and every architect says it, but it is useless to anyone trying to predict what you will actually do.

The report did not lose to a higher-ranked principle. Completeness matters enormously in a reporting system, particularly one used to measure progress against a defined target. But in this situation, the complete version was no longer available, and insisting on completeness would have meant withdrawing information that remained useful. That would have produced a worse failure than giving completeness up.

Every principle I hold has come second to something at some point. The useful question, then, is not which principle sits first, but what decides which one comes second, and whether that decision is made deliberately or simply by whichever pressure happened to be loudest in the room.

I Rank Failures

What I actually rank is not a quality. It is a failure.

When two principles want opposite things, I stop asking which one I value more and start asking what happens if each one loses. Three properties of that failure decide nearly everything that follows.

The first is whether it can be undone. A failure that can be detected, contained, and reversed is a cost. A failure that cannot be reversed is a different category of event, and no amount of upside on the other side of the ledger converts one into the other.

The second is who bears it. Some failures land on the organization that made the decision: the team that chose the design, the budget that funded it, the leaders who accepted the risk. Others land on people who had no part in the decision and no chance to object. I weigh those very differently, and I think anyone who builds systems other people depend on should.

The third is whether anyone would know. A loud failure is expensive, but it announces itself; somebody notices, somebody responds, and the damage has a boundary. A silent failure keeps compounding until it is discovered, usually by the person least equipped to understand what went wrong.

The order follows from those three questions. Each one points the same way every time: irreversible over recoverable, outside the decision over inside it, silent over visible. They do not always agree with one another, and when they disagree, reversibility usually decides, because it is the only one of the three that cannot be corrected later. That is where the genuinely hard calls live, and no ordering removes the need to make them.

Consider a service that delivers regulated information, and an authorization check that occasionally fails for reasons unrelated to whether the requester is actually entitled. One design falls back permissively, so the request succeeds and availability looks excellent. The other fails closed, so the request is refused and a retry or recovery process handles the interruption.

I will choose the second design nearly every time, and the common explanation, that security outranks reliability, is not why.

An outage is visible, recoverable, and borne mostly by the organization that chose the design. An unauthorized disclosure, on the other hand, may be irreversible, is borne by people who never saw the architecture, and is often silent until long after it occurred. Security wins that collision because the failure it prevents ranks higher on all three questions.

Change the system or situation such that delay itself causes harm nobody can take back, and the principles trade places.

The report runs through the same three questions. A rebuild was not on the table. Retiring the report would have produced a failure that was silent, ungoverned, and borne entirely by the people relying on it, in a spreadsheet nobody else would ever see. Shipping with a warning produced a failure that was bounded, visible, and recoverable the moment better data existed.

I don’t rank principles. I rank failures. The principles take their order from the failures they prevent.

A Boundary Is a Principle I’m Not Authorized to Trade

Some collisions I do not resolve at all. Not because I lack an opinion, but because the thing on one side of the scale does not belong to me.

Legal requirements, contractual commitments, authorization boundaries set by the owners of the data, and obligations to people outside the organization all share that property. An architect can weigh them, explain them, and design around them, but what an architect cannot do is trade them away because a deadline is loud. A service-level commitment cannot simply override a privacy requirement, and neither one is mine to override.

That is the distinction I think gets lost when architects describe their priorities as values. Some of what we call principles are really decision rights. They answer the question of who is allowed to make the trade, not which side should win it.

So in practice I sort what is in front of me into three classes.

Boundaries are what I am not authorized to trade. When a boundary collides with something else, the work is to find a design that satisfies both, or to surface the conflict to whoever actually holds the authority to resolve it. Quietly picking a winner is not one of the options.

Priorities are what the system has to achieve: accurate financial figures, availability during a close, recovery inside a committed window. These are where most real tradeoffs happen, and where the failure ranking above does most of its work.

Preferences are how I would like it built: separation of concerns, standardization, reuse, consistency, and elegance. They matter, and they are the principles I give up most often. That is less a failure of discipline than a matter of what preferences are actually for.

Mistaking one class for another produces two very different architects, and I have met both. The first trades away something they had no authority to trade, because the request was urgent and nobody asked whose decision it was. The second refuses to give up a preference because they have mistaken their own taste or previous experience for law.

The first creates incidents. The second creates the reputation that architecture is where projects go to wait.

When the Order Moves

None of those classes is assigned by the name of an engineering discipline. That is the part a ranked list cannot express.

Performance is usually a preference. Faster is better, and slower is tolerable – to a point. Then a query that once returned in two seconds begins taking twenty during a month-end close, and the people depending on it can no longer finish the work inside the window they have. At that point performance is no longer a preference. It has become a priority, because the failure it prevents is no longer an inconvenience but a missed obligation.

Cost behaves the same way. Most of the time it is something to optimize once everything else is protected. Past a certain threshold, though, cost stops being a matter of efficiency and becomes a question of whether the service can continue to exist at all. A design that is correct, secure, and economically unsustainable looks more like a scheduled shutdown than a finished design.

Security moves too. In one place it is a hard boundary set by regulation. In another it is a choice between two acceptable controls, either of which would satisfy every obligation, and the decision between them is mostly about supportability.

What moves in each case is not the principle itself, but the consequence attached to it. The question I am asking stays the same; the answer changes because the failure changed.

That is also why I distrust architectural standards that rank qualities without naming conditions. A standard that says performance is secondary will be quoted, correctly, by someone defending a twenty-second query on the one night of the month when twenty seconds is the difference between closing the books and not.

Losing in Public

Go back to the report, because I left out the most important part of the decision.

The warning was not a courtesy added after the choice was made. The warning was the choice. Without it, the third option becomes the worst of the three: a report that looks complete and is not. That is the failure at the very top of my ranking. It is silent, it is borne by the reader, and it gets harder to undo every time someone acts on it.

With the warning, the same partial report becomes something else. The person opening it knows what they are holding. They know which figures to trust, which to verify elsewhere, and who to ask. The warning could not restore the information that had been lost, and it could not make the partial view complete.

What it could do was preserve an obligation I wasn’t prepared to sacrifice: the person using the report deserved to know what the numbers represented, what they no longer represented, and which conclusions they could no longer reasonably draw.

The decision was imperfect, and pretending otherwise would have made it worse.

That is the closest thing I have to a rule that never moves: a principle may lose, but it may not lose quietly.

When I give something up, the cost of that decision has to land where the people relying on the system can see it. In Borrowed Simplicity I suggested recording, for every exception, the principle that yielded. That record is for the next architect. The warning is the same idea aimed at a different reader: the person actually standing in the consequences.

It also has to say when it ends. A warning without an ending condition becomes wallpaper. People stop reading it, and the limitation becomes permanent by default. Ours named what would retire it: the replacement, now in requirements.

There is one more thing losing in public protects against, and it matters more than it first appears. A failure-first method can very easily become a polite way of transferring cost. Urgent business demands get met, the architecture quietly absorbs the damage, and engineering carries the debt indefinitely because nobody wrote down that it was incurred.

A principle that yields visibly can be paid back. One that yields silently just becomes the next person’s mystery.

Where This Method Is Wrong

I would not trust an essay that defended a decision method without naming where it fails, and this one has a bias I recognize, mostly because it is mine.

Ranking failures favors the failures you can see. An existing system’s failure modes are known. They have been characterized, survived, worked around, and written into somebody’s runbook. A replacement’s failure modes are, by definition, at least partly speculative. Put the two side by side in a failure-first assessment and the incumbent will usually look safer because its problems are familiar, and familiar problems feel like costs while unfamiliar ones feel like risks.

The risk of not changing almost never appears in that comparison. It has already been absorbed into routine: the manual step everyone performs, the reconciliation that runs every month, the person who has to be available on the one day the old process breaks. Nobody experiences any of that as risk anymore. It is just how things work, which is precisely why it never makes the table.

There is a second problem, and it is less comfortable. Nearly every decision I have made this way is easy to defend in a review. I can explain each one, cite the failure it prevented, and show that nothing irreversible happened. That should make me suspicious rather than reassured. A method that never produces a decision I would struggle to explain may simply be a method optimized for the reviewer.

The report is a fair example. Every part of its justification is easy to say out loud in a review, and I am not certain that counts in its favor.

The third is proportion. Not every identifiable failure deserves a control, and a method that ranks consequences without weighing likelihood and the cost of mitigation will eventually build an expensive fence around a very small cliff.

The correction I have settled on is not to abandon the method. It is to stop letting the current state stand outside it. Doing nothing is also an option, and it gets ranked by the same three questions as everything else: What fails if we stay? Who bears it? Would anyone notice?

The incumbent does not get to be the baseline. It is a candidate, and it has to earn its place like the others.

Second Place

So, the order I owed you.

I do not have a first principle in the sense the question usually intends. I cannot tell you that security always wins, or reliability, or anything else with a discipline’s name on it, because I have watched each of them lose for good reasons.

And I have let them.

What I have instead is an order of failures I am unwilling to cause: irreversible before recoverable, outside the decision before inside it, silent before visible, and I try to be honest about the cases where those disagree. I have a set of boundaries I am not authorized to trade, and the habit of sending those conflicts to the people who are. I have preferences I give up often and on purpose.

And I have one rule that has not moved yet: when something loses, I say so, where the person relying on the system can read it.

The report remains available, and the warning remains at the top. Whether that compromise continues to be responsible depends on what happens next: whether the limitation stays visible, whether the remaining information continues to serve its purpose, and whether the replacement eventually allows the warning to be retired. A compromise made responsibly can still become irresponsible if nobody revisits it.

Every principle eventually comes second to something, but I do not think that is a failure of conviction. It is what happens when principles meet a real system with real people on the other end of it.

The question worth asking of any architecture, then, is not what it values first.

It is what it allowed to come second, and whether anyone was told.