Photo by Fr. Daniel Ciucci on Unsplash

Before a stone arch can support its own weight, something else has to hold it up.

Imagine a bridge under construction, somewhere along a river whose current has been cutting through the landscape for longer than anyone remembers. Its foundations have been laid on either bank, and above the water stands a temporary framework of timber, carefully shaped to follow the curve of an arch that does not yet exist.

Stone by stone, the builders begin their work.

Each block is heavy, shaped to fit against its neighbors, and entirely incapable of spanning the river on its own. The first stones lean inward from the supports at either end. Others follow, gradually closing the distance between them, each supported by the wooden framework beneath. Near the crown, the final stones complete the arrangement. The bridge looks nearly finished, but the timber is still doing much of the work.

Then comes the part I find most interesting. The builders begin lowering the temporary supports.

As the centering descends, the weight transfers into the stones themselves. The arch settles into compression, directing its load outward and downward toward the abutments on either bank. Provided the geometry is sound, the materials suitable, and the foundations capable of resisting the resulting forces, the structure begins to carry the burden that the temporary framework had held.

Nothing about gravity has changed. The stones haven’t become lighter, the river hasn’t become narrower, and the material hasn’t acquired some new property that makes it capable of floating above the water. The difference is the arrangement.

Gravity, which would pull an unsupported collection of stones into the river, now produces forces that the completed structure is specifically designed to carry. The bridge does not survive by continually fighting the weight of its own construction. It survives because that weight has somewhere appropriate to go.

There are limits, of course. An arch requires suitable foundations, and gravity is not especially forgiving when they fail. But within the conditions for which it was designed, the structure no longer needs its builders or their scaffolding to stand beneath it.

I’ve spent much of my professional life working with systems that aren’t quite so fortunate. Some are technically sophisticated, carefully documented, and supported by expensive technology. Others are ordinary business processes, built from forms, emails, approvals, and the accumulated expectations of people who have worked together for years.

Many function remarkably well; others function only because someone is constantly holding them together.

We tend to measure the difference after something breaks, when a key employee leaves, a dependency changes, or a previously invisible assumption stops being true. Until then, the distinction is easy to miss. Both systems produce the expected result, and from the perspective of the person receiving it, that is often all there is to see.

But I’ve come to think that one of the most important questions we can ask of a design has very little to do with how well it performs while everyone is watching, and much more to do with what the system becomes when we stop actively correcting it.

The Force Was Never the Problem

An arch is not strong because gravity is weak; it is strong because its geometry establishes a path through which the load can be carried by materials well suited to the forces involved. That distinction matters because we have a tendency, particularly in business organizations, to treat the forces acting upon our systems as though they are unexpected obstacles to successful execution.

People take shortcuts, and departments protect their budgets. Employees forget instructions, resist inconvenient procedures, and prioritize the work they are measured against. Business requirements change, and data arrives late or in unexpected formats. Leadership introduces new priorities before the old ones have been completed.

None of these observations should surprise anyone who has spent a significant amount of time working inside a large organization, and yet we repeatedly design processes that depend upon those conditions not existing.

We establish an approval procedure, discover that people work around it, and respond with mandatory training. We introduce a reporting standard, discover that departments maintain private spreadsheets, and send reminders about the importance of using approved information. We create a workflow requiring three departments to coordinate perfectly, then wonder why somebody has to intervene every Tuesday, until the intervention becomes a meeting each week.

The instinct is understandable; if the process is correct, and people aren’t following it, then the people must be the problem. And sometimes they are. People can behave carelessly, ignore legitimate obligations, or make decisions that no reasonable architecture could have prevented. But when the same deviations recur across different people, teams, and circumstances, I become less interested in asking who failed to follow the process and more interested in asking what the process is asking people to resist.

Convenience is a force. So are time pressure, limited attention, competing incentives, uncertainty, and the ordinary human preference for accomplishing a task without performing additional work that seems unrelated to it.

We can condemn those forces, but the condemnation doesn’t make them disappear.

An architect who designs a system around the expectation that every user will consistently exercise exceptional discipline is doing something remarkably similar to a bridge builder who assumes the stones will simply refrain from falling. The expectation may be sincere, but it is not an engineering solution.

This doesn’t mean every natural tendency should be accommodated, obviously. Some behavior must be restricted, and legitimate controls sometimes introduce unavoidable – or even intentional – inconvenience. There are good reasons financial transactions require independent approval, security boundaries restrict access, and certain actions cannot be completed simply because somebody would find it convenient.

But there is a difference between resisting a force because resistance serves a purpose and resisting it because the design never accounted for its existence.

A sound structure does not eliminate the forces acting upon it. Instead, it gives them somewhere to go.

The Hands Behind the Wall

Consider a reporting environment that refreshes every morning. The dashboards are available when employees arrive. Leadership has the figures it expects, the scheduled processes show successful completion, and the resulting information is sufficiently consistent that nobody has much reason to ask how it got there. From the outside, the system works.

Somewhere behind it, however, an analyst may be correcting source records that never arrive in the expected format, or an engineer may be restarting a dependency that occasionally fails without a meaningful error. Someone in Finance may be manually reconciling differences between systems whose definitions of the same business concept have never quite agreed.

Perhaps there is a particular sequence of operations that must occur whenever a source is delayed, or a report requires manual adjustments because the upstream system cannot represent certain transactions correctly. Perhaps an experienced employee simply knows which discrepancies matter and which can safely be ignored.

None of these arrangements is inherently unreasonable. Temporary accommodations are often necessary, and even well-designed systems require people to investigate unexpected conditions. Real businesses do not stop operating while their architecture is being perfected. The problem begins when the accommodation becomes permanent, while the organization continues to regard the resulting process as self-sufficient.

The reports arrive on time, so the system is considered reliable.

The figures reconcile, so the data pipeline is considered accurate.

The incidents get resolved, so the operational model is considered effective.

Each conclusion may be defensible within the scope of what is being measured. The system is, after all, producing its intended output. What remains invisible is the amount of continuous intervention required to make that outcome possible.

I’ve encountered this often enough to be suspicious of systems described as automated when the description stops at the interface. Automation is not necessarily the absence of human involvement; it may simply mean that the human involvement has moved somewhere the consumer no longer sees. And sometimes that is precisely the right arrangement: a well-run service can expose a simple interface while employing considerable expertise behind it.

But there is a meaningful difference between deliberate human participation in a process and human effort compensating for conditions the process was supposed to handle. The first is part of the design; the second may be holding the design together. Further, the people performing that second function can make the problem remarkably difficult to discover.

An experienced operator knows which error messages are harmless, which failures require immediate attention, and which sequence of interventions will restore service before anyone notices it was interrupted. Their competence improves outcomes, which is exactly what the organization wants, but it also makes the underlying weakness less visible.

A less experienced person might allow the process to fail, generating an incident and forcing an architectural investigation. The experienced person prevents the failure, allowing the organization to proceed without confronting the dependency.

This creates a peculiar contradiction: the more capable the individual becomes at compensating for the structure, the less pressure the organization experiences to improve the structure itself. Eventually, their expertise becomes an implicit part of the architecture, despite appearing in none of its diagrams.

That isn’t an argument against competent people, and it certainly isn’t a reason to allow preventable failures, but it is an argument for recognizing the difference between a system that works because of its design and one that works because somebody knows how to compensate for it.

The distinction may not matter much on an ordinary Tuesday, but it will matter enormously when that person takes a vacation.

Where the Work Wants to Go

One of the simplest examples of structural alignment has almost nothing to do with advanced technology.

Imagine an employee encountering a problem while using a business application. The employee wants help. The organization wants the request entered into its support system so that it can be tracked, categorized, prioritized, assigned, and eventually resolved.

Those objectives are entirely compatible. The employee does not object to accountability, and the organization presumably does not object to resolving the problem.

Yet many organizations manage to construct a process that places unnecessary distance between the two. The employee must leave the application, locate the support portal, authenticate, identify the appropriate service category, select the affected system from a list, explain what they were doing, describe the error, and submit the request.

If they cannot find the right category, they may have to guess. If the form demands information they don’t understand, they may have to ask someone what to enter. Meanwhile, the application is still broken, and the employee still has work to complete.

There is another option; they can message the person who helped them last time. A quick question in Teams might produce an answer in five minutes. If that person cannot solve the issue, they probably know someone who can, so the request never enters the support queue.

The organization now has an accountability problem, incomplete service metrics, and another reminder to send about the importance of following the official ticketing procedure. From the employee’s perspective, however, the system worked exactly as needed. They encountered a problem, found someone capable of helping, and returned to their work.

It would be easy to describe this as a compliance failure, but it is probably more useful to recognize that the formal process required considerably more effort than the informal one, while offering the employee no obvious benefit for that additional effort.

Now change the design. From the employee’s perspective, the solution is almost trivial: put a support button inside the application.

When the employee selects it, the interface already knows which application they are using, and as a result, it can identify the relevant service, collect appropriate technical context, and offer a short form asking what went wrong. If the underlying system supports it, the request can be routed directly into the same centralized ticketing platform the organization already uses.

The employee does not need to know which department owns the application, which service category applies, or where the official support portal lives. They need help, and the button is where the need arises.

The organization still gets its ticket. In fact, it may get a better one, with more reliable classification, less ambiguity, and fewer requests lost in informal conversations.

The governance requirement hasn’t changed. The user’s objective hasn’t changed. Even the system of record may remain exactly the same. What changed is the relationship between the two.

The preferred process became the convenient process.

There is an important architectural distinction here that organizations regularly overlook: centralizing a capability does not require centralizing every interaction with that capability. A single support system can accept requests from many interfaces without surrendering centralized tracking or accountability. The invariant is that the request is recorded, appropriately routed, and managed through a consistent process.

There is no inherent requirement that everyone navigate to the same website in the same way to make that happen, and the same principle applies far beyond technical support.

Employees are more likely to use governed information when it is accessible through the tools they already use. Teams are more likely to provide accurate project updates when the relevant information can be captured during the work itself rather than reconstructed for a weekly status meeting. Approvals are more reliable when the decision-maker receives the necessary context alongside the decision, rather than being asked to investigate it across six unrelated systems.

These are not guarantees, however. Making support requests effortless, for example, can produce its own problems if the interface generates poorly classified tickets, encourages unnecessary escalation, or shifts all of the effort to the support team. Optimizing the convenience of one participant can make the overall system worse.

The objective, then, isn’t to remove every inconvenience; it is to remove friction that serves no necessary purpose while preserving the constraints that do. When those relationships are designed well, people don’t need to think about compliance as a separate activity. The intended behavior is embedded within the ordinary act of accomplishing their work.

The policy hasn’t become more persuasive; the route has become more reasonable.

Gravity Doesn’t Care

There is a problem with everything I’ve argued so far. It’s an important one, because I find the idea of self-sustaining systems enormously appealing, and that preference makes it easy to overlook a fundamental weakness in the analogy.

Gravity does not care where the bridge leads.

A stone arch can be beautifully proportioned, exceptionally durable, and entirely successful at carrying the loads placed upon it. But none of those qualities establishes that the bridge should have been built, that it connects places worth connecting, or that its existence benefits the people living around it.

Its structural stability says very little about its purpose. Similarly, organizations can be stable in exactly the wrong way. Consider a business that places substantial emphasis on predictable project delivery.

Its leaders are measured on whether initiatives are completed within approved budgets and schedules. Missed deadlines attract scrutiny, cost overruns require explanation, and successful delivery is rewarded. These are reasonable objectives; organizations have limited resources, and accountability for spending and execution is entirely appropriate.

Over time, however, the system begins to shape behavior. Managers become cautious about accepting projects with uncertain requirements. Teams favor work with clearly defined deliverables over initiatives whose value may be substantial but difficult to quantify. Risks are managed, sometimes by reducing them, and sometimes by ensuring they do not become visible until a commitment has already been made.

Project proposals become increasingly polished. Estimates become carefully negotiated, and the most successful managers learn which kinds of work can be delivered predictably enough to protect their performance metrics.

Nobody has instructed them to avoid valuable opportunities, and nobody has directed them to conceal uncertainty. Each person is responding rationally to the consequences attached to the choices available to them. And, as a result, the organization may become exceptionally good at delivering the projects it chooses to approve, while growing steadily worse at choosing projects worth delivering.

Its structure is working, but the outcome is wrong.

Approval processes can produce a similar result. Suppose that several departments must approve a proposed change, and that an approver who accepts a risky decision may later be asked to explain the consequences. An approver who delays the decision, requests another review, or asks for additional information faces much less immediate exposure. Eventually, the safest individual behavior becomes avoiding definitive responsibility.

The organization has established a process intended to manage risk, but its incentives may reward the avoidance of decisions more reliably than the quality of the decisions made.

Every participant can be acting reasonably within their role, and the collective result can still be unreasonable. This is why I would be cautious about celebrating equilibrium as an achievement in itself.

A dysfunctional bureaucracy may be highly stable, just as a poorly designed compensation structure may reliably produce exactly the behavior it rewards. An inefficient process can survive for decades because the people most empowered to change it are also those most insulated from its costs.

These systems do not necessarily persist because nobody has recognized their problems. Sometimes they do so because their internal relationships make continued existence the most convenient outcome for the people operating within them.

They have settled into a shape; it simply isn’t the one their designers intended, or at least not the one their stated purpose would justify.

There is a temptation to describe these outcomes as entropy, as though organizations naturally drift toward disorder when left alone. The analogy is useful to a point, but it can also obscure the mechanism; entropy in thermodynamics has a specific meaning, and an organization is not a sealed physical system passively progressing toward one inevitable state. People make decisions, incentives change, new resources enter, and feedback alters behavior.

What matters is that repeated interactions under relatively stable conditions can produce persistent patterns, including patterns nobody explicitly chose. At times the result looks like disorder. At others it looks remarkably organized. Sometimes the most dangerous outcome is a system that becomes increasingly efficient at sustaining something it should have learned to abandon.

Stability is a property; it is not a virtue. That distinction should guide what we try to preserve.

Designing for the Descent

If the objective is not simply to create a self-sustaining system, then we need to be more precise about what the system is supposed to sustain. In architecture, I find it useful to distinguish between the arrangement we happen to have chosen and the properties that must remain true for that arrangement to serve its purpose.

Those are not the same thing. A reporting platform might depend on a particular database today, use a different integration architecture next year, and eventually move to a technology its original developers have never encountered.

None of those changes necessarily undermines its purpose.

What matters is whether the information remains accurate enough for its intended use, whether its meaning is preserved, whether access remains appropriately governed, and whether the people relying on the information can recognize material limitations. The implementation is allowed to change, but those underlying obligations are not casually negotiable.

In engineering and software design, we often describe properties that must remain true as invariants. The term is useful, although it carries a risk of making those properties sound more permanent than they really are. An invariant is not necessarily a universal truth. It is a condition that the system has been designed to preserve within a defined scope.

Consider a new data source being introduced into an existing reporting environment. The source contains familiar concepts: customers, transactions, products, dates, and amounts. It would be convenient to assume that those concepts behave exactly as they do in the systems already integrated. Customers have identifiers, after all. Transactions have dates. Products have numbers.

A straightforward implementation might map the fields, add the records to the existing data model, and allow downstream reports to consume the result. The problem is that familiar names do not guarantee equivalent meaning. A customer identifier may be unique only within a particular company or source system. A transaction date may represent posting rather than invoice generation. A product amount may be expressed in a different currency or unit of measure, or an adjustment may use a convention that reverses the sign expected by the reporting model.

The integration might execute successfully, and its outputs might look perfectly reasonable. Neither necessarily guarantees that the resulting information is correct.

A more deliberate architecture identifies the assumptions that matter before the source is allowed to participate in the shared model. It defines the necessary relationships, validates key fields, establishes how incompatible records will be handled, and ensures that unexpected conditions cannot silently alter the meaning of information that is already being published.

This doesn’t mean rejecting every imperfect record or suspending every report whenever an upstream system behaves unexpectedly. Sometimes the responsible choice is to preserve the information that remains valid while making its limitations explicit. Sometimes the correct response is to quarantine affected records. Sometimes publication genuinely must stop. The choice depends on the consequences of each failure, not on a universal preference for either continuity or strictness.

The important difference is that the architecture contains mechanisms for recognizing when its assumptions have been violated. This is more than making the system resistant to change: it is making change observable.

Observation matters because systems do not always fail dramatically when they cease serving their purpose. A database can continue responding to queries while returning misleading information, just as a workflow can continue reaching its final status while skipping an important review step, and a support process can close tickets efficiently while failing to resolve the problems that caused people to open them.

The interface may continue reporting success long after the underlying objective has been compromised. A useful design therefore needs feedback capable of distinguishing continued operation from continued correctness. That feedback also has to be connected to consequences.

A validation rule that identifies incompatible records but allows them to flow into production without warning is not much of a safeguard. And a dashboard showing an increasing backlog is useful only if someone has both the responsibility and the practical ability to respond. Instrumentation does not become governance merely because somebody gave the graph a title.

The architect’s task, then, is not only to determine which relationships must be preserved, but to distinguish the failures a system is authorized to correct from the evidence that those relationships themselves need reconsideration.

A malformed record can be rejected according to an established data contract. But a growing number of otherwise valid records being rejected by that same contract may indicate that the contract has stopped representing the business correctly.

The first problem can be resolved within the architecture. The second calls the architecture itself into question.

And that raises a more difficult question: who decides when an obligation itself has stopped being appropriate?

When the Ground Moves

Return to the bridge.

A well-built masonry arch may stand for centuries because its geometry directs ordinary loads into materials and foundations capable of carrying them, but that stability is conditional. The arch depends upon the abutments remaining capable of resisting its thrust, the foundations continuing to support the structure, and the loads remaining within tolerable limits.

Undermine one of those conditions, and the properties that once made the arch dependable may no longer be sufficient. The structure has not necessarily been poorly designed; its environment may simply have moved beyond what the design could accommodate.

Organizations have foundations too, although theirs are considerably harder to inspect. A process may depend upon a stable regulatory environment, a particular business model, an established division of responsibility, or a shared understanding of what the organization is trying to accomplish.

A technical architecture may assume certain volumes of data, classes of users, trust boundaries, or patterns of interaction. Sometimes those assumptions are explicit, and often they are so familiar that nobody thinks to write them down.

Then the business acquires another company, or a new requirement introduces a category of information the original security model never accounted for, or a previously internal service becomes available to external customers. An organization restructures, and the decision rights upon which an approval process depends no longer align with the people performing the work.

The old system may continue functioning exactly as designed, and in some cases, that becomes the problem. The forces acting upon it have changed, but its arrangement has not.

I think this is where the preference for passive stability must be treated with some skepticism; there are systems in which continuous adjustment is not evidence of architectural weakness. Instead, it is the architecture.

A thermostat maintains temperature by measuring conditions and making corrections. Many industrial control systems depend upon continuous feedback. Aircraft flight-control systems may make adjustments that no fixed passive arrangement could provide across the full range of conditions they must handle.

The fact that a system requires active control does not make it inferior. The meaningful distinction is between correction that has been deliberately designed as part of the system’s function and correction required because the system cannot reliably fulfill that function as designed.

A thermostat is not failing because it turns the heat on. Conversely, it would be failing if someone had to stand beside it, checking the room temperature and manually adjusting the furnace every twenty minutes because the control mechanism couldn’t be trusted.

This suggests that stability, recoverability, and adaptability deserve to be considered separately. A stable system continues functioning under the conditions it was designed to encounter. A recoverable system can return to acceptable operation after a disturbance. An adaptable system can change its behavior or implementation in response to new circumstances while preserving the properties that matter.

A system can possess any one of those qualities without possessing the others, and even adaptability has limits. A system that automatically adjusts to every observed change may adapt itself away from the purpose it was intended to serve. If a process begins optimizing for fewer complaints by making complaints more difficult to submit, its measured performance may improve while the underlying service deteriorates. The feedback loop has not failed mechanically, but it has optimized the wrong outcome.

At some point, no amount of internal correction can answer the question of whether the system is still pursuing the right objective. That requires judgment from outside the mechanism being evaluated.

Sometimes the foundations need repair; other times, the structure needs redesign. And occasionally, the correct decision is that the bridge no longer needs to go where it once went.

The Work That Remains

I don’t think the objective of architecture should be to eliminate human involvement; that would be an odd ambition for systems whose reason for existing is usually to serve human purposes.

What I want to eliminate, where reasonably possible, is the need for people to compensate continually for problems that a better arrangement could prevent. There is a difference between using human judgment where judgment adds value and consuming it because the system has failed to account for ordinary conditions.

A support specialist should spend their expertise understanding and resolving problems, not repeatedly explaining where the request form is located. A data engineer should spend time improving the reliability and meaning of information, not performing the same corrective operation every morning because an upstream dependency was never addressed. A manager should spend attention on decisions that genuinely require judgment, not continually reminding people to complete administrative steps that could have been incorporated into the work itself.

The improvement isn’t that people become unnecessary, but that their attention becomes available for work that actually benefits from having a person involved.

But this cannot be the end of the argument, because a system that requires fewer interventions can also become better at concealing the need for intervention.

Return to the support button: suppose we implement it successfully. Employees can submit requests from the applications they use, tickets arrive with the correct classifications, and the support organization can track its activity accurately.

That’s an improvement.

Now suppose the volume of requests grows, response times gradually increase, and users begin reporting that tickets are routinely closed without their underlying problems being resolved. The submission mechanism is still working as designed, and the ticketing process might even report excellent compliance and closure rates.

Yet the system may have stopped serving the people who depend upon it. We improved the route into the process without necessarily improving what happens after arrival. The difference matters because every design defines what is easy to observe, what is easy to measure, and what the organization is likely to treat as evidence of success.

If the only feedback we preserve concerns whether the prescribed process was followed, we may create a system that is exceptionally capable of demonstrating compliance while becoming progressively less capable of fulfilling its purpose.

The architecture must therefore make room for disagreement with its own measures of success.

The user who says the problem isn’t resolved may possess information that the ticket’s status does not capture. The employee who works around a process may be revealing an obstacle that its designers underestimated. The team that regularly requests an exception may be demonstrating that the standard no longer reflects the environment in which it operates.

None of those observations automatically proves the system is wrong, but each offers evidence that the intended outcome and the actual outcome may have diverged. A mature system needs a way to receive that evidence without assuming that the person providing it is the problem. It also needs people with the authority to act upon what the evidence reveals.

That is why I distinguish reducing dependence on individual intervention from removing judgment entirely. A system can enforce the rules it has been given, and it can reveal when those rules are violated. It cannot establish, from those observations alone, that the rules themselves deserve to be preserved. We still need people capable of questioning the purpose, challenging an assumption, recognizing an unforeseen consequence, and deciding when an arrangement must change.

Their responsibility should be to make those judgments deliberately, rather than spending their attention continuously compensating for ordinary conditions the system was meant to handle.

The Shape It Falls Into

There is something beautiful about the moment a completed arch begins to carry its own weight. The temporary framework descends, the load transfers, and the structure demonstrates that its geometry can do what its builders intended.

The stones remain stones, and gravity remains gravity. Nothing about the environment has become more accommodating, and the bridge has not developed a determination to remain standing.

Someone understood the forces involved well enough to arrange the materials around them. That is the achievement, but it isn’t the whole achievement.

That achievement remains conditional. The foundations must hold, the loads must remain within the structure’s tolerances, and someone must recognize when those conditions have changed. And even if the bridge continues to stand, its strength tells us nothing about whether it still leads somewhere worth going.

The same is true of the institutions and technologies we build. Their continued operation is meaningful only insofar as they remain capable of serving a worthwhile purpose. We can arrange their constraints and incentives so that ordinary behavior reinforces that purpose, but we cannot delegate the responsibility for evaluating it to the arrangement itself.

A good architecture should not require its maintainers to spend their lives preventing it from becoming what its design naturally encourages. It should make the intended outcome sustainable, deviations visible, and necessary changes possible without forcing everyone to rediscover how the structure was supposed to work. And when the environment changes enough that the intended arrangement no longer serves its purpose, we should be willing to change the arrangement rather than demand that people compensate for it indefinitely.

I don’t think the highest achievement of engineering is a structure that never moves, never requires attention, or never changes. It is understanding the forces acting upon something well enough to know what those forces will do, what the structure must preserve, and when the relationship between them is no longer sound.

Because every system we build will eventually be subjected to conditions we cannot fully control.

The question is not simply whether it will stand when we let go; it is what shape it will settle into, what that shape will sustain, and whether the result is still something worth holding up.