Innovation is often associated with creating something new. We improve a component, replace an outdated technology, or invent an entirely new one. These innovations can be incremental — making something better — or radical — introducing something fundamentally different. But there is another axis of innovation that often goes unnoticed: innovation that emerges not from changing the individual parts, but from changing how existing parts work together.

Rebecca Henderson and Kim Clark called this architectural innovation. Their insight was deceptively simple: organizations can create tremendous value by reconfiguring existing technologies rather than inventing new ones. The components remain largely the same, but the architecture — the relationships between those components — changes. History has repeatedly shown that these changes can be just as disruptive, and often more valuable, than technological breakthroughs.

This perspective has profound implications for IT organizations.

Too often, IT innovation is framed as a technology discussion. Should we adopt cloud-native platforms? Should we introduce AI? Should we modernize our ERP system? Should we replace legacy applications? These are important questions, but they are primarily questions about components. They assume that innovation is driven by selecting better technologies.

In reality, organizations rarely suffer from a lack of technology. They suffer from an inability to connect technology in ways that create new business capabilities.

This is where the role of the IT architect fundamentally changes.

Traditionally, architects have been seen as technical specialists responsible for standards, reference architectures, and governance. They ensure systems fit together, technologies are selected consistently, and technical risks are managed. Those responsibilities remain important, but they are no longer sufficient.

The modern IT architect should be viewed as an architect of change.

Architects operate at the intersection of business strategy, technology, data, and organizational design. Their unique contribution is not simply knowing individual technologies, but understanding the relationships between them. They recognize dependencies that others overlook. They see opportunities for reuse, integration, and simplification. More importantly, they understand that changing relationships often creates more value than replacing individual systems.

This requires systems thinking.

A systems thinker does not optimize isolated components. They optimize the performance of the entire system. Improving one application while creating bottlenecks elsewhere is not innovation. Introducing artificial intelligence into a fragmented landscape without addressing data quality and process integration rarely creates sustainable value. Real innovation emerges when technologies, processes, people, and information reinforce one another.

This is architectural innovation in practice.

Consider how many organizations pursue digital transformation. Departments independently purchase SaaS solutions, automate individual processes, and introduce specialized tools. Each initiative may be successful on its own, yet the organization often becomes more fragmented. Integration becomes expensive, data becomes inconsistent, and employees struggle with increasingly complex digital environments.

An architectural perspective asks a different question.

Instead of asking, “What new technology should we buy?” it asks, “How should our capabilities work together to achieve our strategic goals?”

That subtle shift changes everything.

It moves the conversation from technology selection to capability design. From applications to business outcomes. From projects to ecosystems.

In this sense, architecture becomes a strategic discipline rather than a technical one.

Architects help organizations see beyond today’s projects toward tomorrow’s operating model. They define principles that encourage flexibility rather than rigidity. They identify common capabilities that can be shared across business units. They create platforms that allow innovation to happen repeatedly instead of through isolated initiatives.

Perhaps most importantly, architects provide a coherent vision.

Organizations naturally evolve through hundreds of local decisions. Every project makes reasonable choices within its own scope. Over time, however, these local optimizations often produce global complexity. Without an architectural vision, complexity accumulates until innovation becomes slow, expensive, and risky.

A compelling IT architecture provides direction without prescribing every detail. It defines the desired characteristics of the future landscape: modular, interoperable, data-driven, secure, and adaptable. It allows individual teams to innovate while ensuring their innovations strengthen the whole rather than fragment it.

This is why architecture should not be viewed as documentation. It is a shared vision of how technology enables the organization to achieve its purpose.

The best architects therefore spend as much time communicating as designing. They create alignment across business leaders, product teams, engineers, security specialists, and operations. They translate strategic ambitions into architectural principles and ensure that individual investments contribute to long-term organizational capabilities.

In an era of AI, cloud computing, digital ecosystems, and rapidly changing business models, this role becomes even more important. Organizations will continue to adopt new technologies at an accelerating pace. The competitive advantage will rarely come from adopting those technologies first. It will come from combining them better than competitors.

That is architectural innovation.

The future of enterprise architecture is therefore not about drawing more diagrams or enforcing stricter governance. It is about enabling organizations to continually recombine existing capabilities into new sources of value. Architects become designers of adaptability rather than custodians of technology.

If innovation is about creating the future, then the architect’s role is not merely to build systems. It is to shape the connections that allow an organization to evolve.

And in a world where technologies change faster than organizations can replace them, the ability to redesign relationships may well become the most valuable capability of all.

Architectural Innovation was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every great work of art, design, or architecture contains a paradox.

It looks free. Effortless. As if the rules never existed. As if the creator simply saw something and made it real without constraint or struggle.

But behind every work that transcends the rules is someone who paid a very big, very difficult price to get there.

Three prices, actually. One for each phase of the journey.

Shu — The Price of Submission

The first phase is called Shu. Follow the rules. Learn the forms exactly as they are taught. No improvisation. No shortcuts. No expression of your own taste until you have earned the right.

This sounds simple. It is not.

Shu requires the suspension of everything that feels most alive in a creative person — the instinct, the opinion, the desire to make something that is yours. The student who arrives at art school, at architecture school, at a music conservatory, burning with something to say — is asked, first, to be quiet. To copy. To repeat. To do it the way it has been done for centuries, whether or not it feels right, whether or not it feels like them.

The temptation to skip this phase is enormous. Especially for talented people. Especially in a culture that celebrates originality and treats imitation as lesser. Why copy the masters when you could be developing your own voice?

Because the rules are not arbitrary. They are accumulated wisdom — centuries of practice, failure, refinement, and hard-won understanding about what works and why. The proportions of classical architecture were not invented by committee. They were discovered through generations of observation about what the human eye finds coherent. The rules of counterpoint in music encode thousands of hours of listening to what creates tension and resolution, dissonance and harmony.

To skip Shu is to cut yourself off from all of that accumulated intelligence. To insist on reinventing, from scratch, what others already understood.

The student who genuinely submits to Shu — who learns the rules not as external constraint but as inherited knowledge — is building something invisible and essential. A foundation. Not for following the rules forever. For understanding them deeply enough, eventually, to know when and why to leave them.

That foundation takes years. It is unglamorous. It produces work that is correct rather than original. And it requires something that many talented people find genuinely difficult: the humility to be a beginner for long enough that the learning actually happens.

Shu is the realm of the craftsman.

Ha — The Price of Breaking

The second phase is Ha. Break the rules.

This sounds appealing. Liberating. After years of submission, finally — freedom. Finally the permission to question, to depart, to make something that bears your own mark rather than the tradition’s.

But Ha is not what it sounds like from the outside.

Breaking the rules from mastery is completely different from breaking them from ignorance. The first produces something new. The second produces work that is technically free and humanly empty. And from the outside, they can look similar — which is one of the cruelest traps in creative practice.

The student who breaks the rules in Shu — who improvises before the foundation is built, who rejects constraints they haven’t yet understood — is not in Ha. They are still in Shu, refusing to pay its price. The apparent freedom is not transcendence. It is avoidance.

Genuine Ha is earned, not claimed. It comes when the rules are understood deeply enough that their exceptions become visible — when you can see not just what the rule says but why it exists, what it is trying to achieve, and in what specific circumstances departing from it serves a deeper purpose than following it.

Picasso’s academic drawings, made at fourteen, were technically flawless. The cubism that followed was not ignorance of classical representation. It was the transcendence of someone who had mastered representation so completely that he could see through it to something it couldn’t express — and had the technical command to build something new on the other side.

The price of Ha is also a social one. Breaking the rules means being wrong — visibly, publicly — some of the time. It means producing work that makes people uncomfortable. That invites the judgment of those who measure quality by adherence to the tradition you are departing from. That exposes you to the criticism that you simply don’t know what you are doing.

Some of that criticism will be right. Breaking rules intelligently requires testing, failing, learning, and breaking again more precisely. It is not a single act of liberation. It is a long, iterative, uncomfortable process of finding where the rules are limiting and where they are still right.

And here is what makes Ha genuinely difficult to complete: the comfort it eventually offers. A practitioner who has learned to break rules intelligently — who has developed a signature, a recognisable departure from convention — can settle there. The breaking becomes its own convention. The rebellion becomes its own rule. Many practitioners live their entire careers in this space, performing Ha without ever reaching what it was supposed to lead to.

Ha is the realm of the rebel.

Ri — The Price of Letting Go

The third phase is Ri. Transcend the rules.

Of the three, this is the one most easily described and least easily understood.

It sounds like the reward. The destination. The place where the long difficulty of Shu and the uncomfortable uncertainty of Ha finally resolve into something effortless and free.

It is not a reward. It is the most demanding thing of all.

Because what Ri requires is not the acquisition of something. It is the release of something. Several things, actually.

The release of the rules. Not the rules themselves — by Ri the rules have been so deeply internalized that they are invisible. But the conscious relationship with them. The habit of checking decisions against the tradition. The internal voice that says: is this right? Does this follow the principle? This voice was useful in Shu and necessary in Ha. In Ri it is the last obstacle. The practitioner who still needs to verify their decisions against a framework has not yet reached transcendence — they have reached very sophisticated rule-following.

The release of the identity. This is harder. Most serious practitioners have built their professional identity around their expertise. Around being someone who knows. Who has mastered the discipline. Who can be trusted to make the right decisions because of their deep knowledge of the tradition. This identity is real and earned. It is also, at a certain point, a cage. The practitioner who cannot act without the validation of being seen as an expert cannot act from Ri. Because Ri produces work that sometimes looks inexplicable from the outside — that cannot be defended by reference to the rules, because it has moved beyond them. Holding the identity of the expert and reaching Ri at the same time is very difficult. Often impossible.

The release of the mind. This sounds dramatic. It is. The Japanese martial arts tradition that gave us Shu Ha Ri also gave us the concept of mushin — no-mind. The state in which action arises without the intermediary of conscious thought. The master swordsman who does not think about the cut — who has practized so deeply that the technique has dissolved into the body, into the nervous system, into something below the threshold of deliberate decision.

This is what Ri looks like from the inside. Not the conscious application of transcendent wisdom. The absence of the machinery of conscious application entirely.

Getting there requires, at some point, losing what most people think of as their mind — the constant internal commentary, the evaluation, the comparison, the judgment. The voice that narrates the work as it is being made. That voice served a purpose. In Ri it has to go.

Many practitioners spend a lifetime approaching this and never arriving. Not because they lack talent or discipline. Because the letting go is genuinely terrifying. The mind that has to be released is also the mind that has been keeping you safe — that has been managing the quality, maintaining the standard, preventing the failures that have consequences. Releasing it requires a quality of trust that is, in the end, not a technique but a kind of courage.

Ri is the realm of the artist.

Why the Work That Transcends Rules Is Rooted in Them

There is a reason why the work that feels most free is almost always produced by someone with the deepest foundation.

Tadao Ando spent years studying every great building he could visit before developing the radical simplicity of poured concrete and natural light that is unmistakably his own. The simplicity was not the absence of knowledge. It was knowledge so fully absorbed that it had become invisible.

Miles Davis said that you have to learn everything, then forget it all and just play. The forgetting is not the loss of what was learned. It is the completion of the learning — the point at which knowledge has moved from the conscious mind into something deeper.

The rules are not the enemy of transcendence. They are its foundation.

But you have to be willing to pay all three prices.

The long submission of Shu — longer than feels reasonable, longer than culture tells you is necessary.

The uncomfortable, iterative, sometimes publicly wrong process of Ha — without settling into rebellion as its own identity.

And the genuine, terrifying release of Ri — the identity, the mind, the safety of knowing.

Most people stop at Shu. Some reach Ha and stay there. Very few pay the full price.

But the work they produce — the work that carries the tradition without being contained by it, that breaks every rule without breaking the spirit behind them, that feels both inevitable and completely new — that work is why the price is worth paying.

The Price of Transcendence — Shu Ha Ri and the Long Road to Great Design was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kintsugi is the Japanese art of repairing broken pottery with gold.

The crack is not hidden. It is highlighted. Made visible. Celebrated.

The philosophy behind it is simple and radical: the breaking is part of the object’s history. The repair is part of its beauty. Something that has been broken and mended is not diminished — it is richer than it was before.

We tend to think of breakage as failure. Something to hide, to fix as invisibly as possible, to move past as quickly as we can.

Kintsugi says the opposite. The fracture is where the gold goes.

But there is something deeper still.

Things don’t break without reason.

A system breaks at the exact point where the design met a reality it wasn’t built for. The fracture is not random. It is precise. It reveals where the stress actually lives. Where the assumptions were wrong. Where the design was insufficient in ways nobody had seen yet — until reality showed them.

The break is not noise. It is signal.

When something breaks in IT architecture, in a development process, in any complex system — that breakpoint is information the design review never could have provided. Because the design review tests against what you imagined. The failure tests against reality.

The organizations that treat failure as an embarrassment — patching quickly, moving on, hiding the crack — lose that information. They fix the symptom and the same fracture appears somewhere else later. Because the underlying condition was never understood.

The organizations that treat failure as diagnostic — that ask not just how do we fix this, but what is this telling us — come out stronger. Not despite the breaking. Because of it.

The gold in kintsugi is not decorative.

It is what you pour into the place where reality revealed itself.

The cracks are not where the system is weak.

They are where the system becomes wise.

“The world breaks everyone and afterward many are strong at the broken places.” — Ernest Hemingway

Kintsugi — things don’t break without a reason was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Systems thinking is a way of seeing the world through relationships rather than parts. It looks at patterns, feedback loops, and conditions.

That one sentence opens up a completely different way of practising architecture.

Two Ways of Seeing

There are two complementary ways of understanding complex systems.

The first is analytical thinking — breaking the whole into parts, understanding each part deeply, solving specific problems precisely. This approach is enormously powerful. It built modern engineering. It produced the technical expertise that makes IT possible. It is the foundation of everything.

The second is systems thinking — keeping the whole in view, looking at the relationships between parts, understanding the patterns and conditions that produce the behavior you are observing.

In a complicated system — a machine, a well-defined process, a deterministic algorithm — analytical thinking is often sufficient. The parts are relatively independent. Understanding each one separately gets you most of the way there.

In a complex system — an organisation, a living ecosystem, an IT landscape with hundreds of applications, dozens of teams, years of accumulated decisions — something more is needed. The parts are deeply interdependent. Everything affects everything else. The system produces behaviors that none of its individual components possess on their own.

This is where systems thinking becomes not just useful but essential.

The two approaches are not in competition. They are complementary. The architect who brings both — analytical depth and systems vision — sees more, designs better, and intervenes more effectively than either alone can achieve.

Relationships, Not Just Parts

The shift that systems thinking invites is a shift in what you look at.

Not only the components — but the relationships between them. Not only the current state — but the patterns that produced it. Not only the visible behavior — but the feedback loops that sustain it. Not only what is broken — but the conditions that make certain outcomes more likely than others.

A river flooding is not only a problem with the river. It is an expression of the system of rainfall, land use, drainage, and human settlement that the river is part of. Address the conditions and the flooding stops — not just in one place, but everywhere downstream.

An IT landscape that keeps accumulating complexity is not only a problem with any particular application or team. It is an expression of the system of incentives, governance, architectural oversight, and decision-making conditions that the landscape is embedded in. Change the conditions and the whole landscape begins to move in a different direction.

The architect who sees parts designs better components.

The architect who sees systems designs better conditions.

Both matter. Together they are extraordinarily powerful.

Feedback Loops

At the heart of systems thinking is the feedback loop — the mechanism by which a system’s outputs become its inputs, shaping its own future behavior.

There are two kinds.

Reinforcing loops amplify whatever is already happening. Growth produces more growth. Momentum builds momentum. In a well-governed IT landscape, this works beautifully — good architectural decisions create the conditions for more good decisions, coherence begets coherence, and the system becomes progressively easier to evolve.

Balancing loops constrain and stabilise. They push back against drift, maintaining a target state. An architectural governance function is a balancing loop — when the landscape begins to drift from the target architecture, governance provides the counterforce that brings it back.

Understanding both kinds of loops gives the architect a new set of questions. Not just: what should I design? But: what forces in this system will naturally push toward coherence? How do I amplify those? And where do I need to introduce a balancing force to prevent drift?

Designing feedback loops is one of the highest-leverage things an architect can do. And it is almost entirely absent from conventional architecture practice.

Emergence

Complex systems produce properties that none of their individual parts possess.

This is called emergence — and it is one of the most fascinating dimensions of systems thinking for IT architecture.

The culture that forms around a platform emerges from the daily experience of thousands of people using it. Nobody planned it. It arose from the interactions — from the feedback loops between the system’s design and the human behavior it shapes.

The remarkable coherence of a well-governed IT landscape — where every component seems to fit, where change is natural rather than traumatic, where the whole feels alive — is also an emergent property. It cannot be achieved by optimising individual components. It arises from the quality of attention brought to the relationships between them.

Alexander called this wholeness. It is not located in any part. It lives in the interactions. It emerges from the conditions.

Understanding emergence gives the architect a completely different ambition. Not just: how do I design this component well? But: what conditions will allow the whole system to become what it needs to be?

That is a richer and more powerful question.

Conway’s Law as Systems Thinking

One of the most powerful insights in software architecture is a pure expression of systems thinking.

Conway’s Law states that organisations design systems that mirror their own communication structures.

The social system and the technical system are not separate. They are coupled — shaping each other through feedback loops that run in both directions. The organisation influences the architecture. The architecture influences how the organisation works. Both are part of one system.

The implication is liberating. If you want to understand why an IT landscape looks the way it does — its boundaries, its integrations, its coherence or lack of it — look at the organisation that built it. The architecture is a mirror.

And if you want to change the architecture, you have two levers instead of one. You can change the technical design. You can also change the organisational conditions. Often the second is more powerful than the first.

This is the gift of systems thinking. It expands the architect’s range of intervention from the technical to the human — and finds leverage in places that purely technical thinking never reaches.

Leverage Points

Donella Meadows — one of the great systems thinkers of the twentieth century — wrote about leverage points: places in a system where a small change produces large effects.

Her insight was counterintuitive and important: the highest leverage points are often not where the most visible problem is.

The most visible interventions — adding resources, scheduling cleanup, redrawing the architecture diagram — address the accumulated state of the system. They are often necessary. But the deeper leverage lies in the conditions that produce the accumulation. The governance model. The incentive structure. The architectural ownership. The conditions under which decisions get made and by whom.

Change these and the whole system shifts. Sustainably. Without requiring continuous intervention.

The architect who understands leverage points adds a new question to their practice: not only what needs to change, but where in the system a small change will produce the largest effect. That question leads to interventions that are quieter, less dramatic, and far more durable than the ones that address symptoms directly.

Seeing the Whole

There is a quality of attention that systems thinking requires — and cultivates.

Not the attention that fixes on the part. The attention that holds the whole.

Not the attention that sees the component in isolation. The attention that sees the relationships — the feedback loops, the emergent properties, the conditions — that the component is embedded in.

The hunter in the forest does not see only individual animals. He sees a system — tracks and patterns and relationships and conditions that tell a story about what has happened and what is likely to happen next.

The great IT architect sees the same way.

Not a collection of applications and integrations. A living system — of technical components, human behaviors, organisational incentives, data flows, cultural conditions — that produces the landscape they are looking at.

And when they intervene, they intervene at the level of the system. Not only patching parts. Changing conditions. Designing feedback loops. Creating the circumstances from which coherence is the natural emergent property.

An Expanded Foundation

Component thinking and systems thinking together form a complete architectural practice.

The technical depth to design well. The systems vision to see the whole. The understanding of feedback loops to design for coherence over time. The awareness of emergence to create conditions rather than just components. The knowledge of leverage points to intervene where it matters most.

Systems Thinking — An Expanded Vision for IT Architecture was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every child is born curious.

Most lose it.

Not dramatically. Gradually. Through years of being taught that questions slow things down. That there is a correct answer and the goal is to find it fast. That not knowing is a weakness to be hidden rather than a doorway to be walked through.

By the time most people enter professional life the curiosity has been efficiently replaced by something safer. Pattern recognition. Best practices. Proven frameworks. The comfort of already knowing.

Curiosity cannot be taught.

But it can be killed. And it usually is.

It can also be rekindled — given room to breathe, modelled by someone who never lost it, protected in an environment that rewards genuine questions over confident answers.

When I recruit IT architects I look for many things.

Technical depth. Business understanding. The ability to hold complexity without collapsing it prematurely into a solution.

But above all I look for curiosity.

Not the performed curiosity of someone who asks good questions in interviews. The real kind. The kind that makes someone genuinely want to know what is underneath the surface of a problem. That makes them uncomfortable with the obvious answer. That makes them ask one more question when everyone else in the room has already moved on.

Because architecture is design. And design is — at its core — the discipline of questioning things. Genuinely. Deeply. Without already knowing what the answer should be.

Curiosity is what gets you under the surface.

And that is where great design is born.

Not in the patterns repeated from the last project. Not in the framework applied because it worked before. Not in the best practice that everyone agrees on because nobody has questioned it recently.

In the specific, unrepeatable reality of this problem. This organization. These people. This moment.

That reality only reveals itself to someone who genuinely wants to know what is there.

Fifty years of experience without curiosity is fifty years of drawing the same symbol over and over.

Two years of experience with genuine curiosity is two years of seeing more clearly every day.

I would rather build with the curious beginner than the incurious expert.

Every time.

Curiosity Cannot Be Taught. But It Can Be Killed. was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

“That’s not realistic.”

Three words. Said casually. Often kindly. With the best intentions.

And yet.

Something happens when those words land. Something small and important goes quiet. The idea that was alive a moment ago — that was reaching toward something, that had energy and direction and the particular aliveness of a thing not yet constrained — retreats.

Not forever. The first time.

But the words come again. In different forms. From different directions.

It’s difficult. That’s not how things work here. You have to be practical. Let’s be realistic. That’s a nice idea but…

And gradually — not dramatically, not in a single moment you can point to — the retreat becomes a habit. The reaching stops happening automatically. Before the idea can fully form, something inside checks it against what is allowed. Against what is realistic. Against what the world has repeatedly indicated it will accept.

The practical voice stops being external.

It moves inside.

And then you are doing the work of your own limitation without anyone else having to bother.

What Practicality Actually Is

Practicality presents itself as wisdom. As maturity. As the hard-won understanding of someone who has learned how the world actually works.

And sometimes it is those things. The ability to navigate constraints, to understand what is possible in a given context, to work with reality rather than against it — these are genuine skills. Valuable ones.

But there is a version of practicality that is something else entirely.

It is fear wearing the mask of wisdom.

The fear of failure dressed as realism. The fear of standing out dressed as humility. The fear of wanting something and not getting it — which is perhaps the deepest fear of all — dressed as the mature acceptance of how things are.

It’s not realistic is sometimes an accurate assessment of the situation.

But it is also one of the most effective weapons ever developed for killing the thing in a person that wants to reach beyond what is already known to be possible.

Because realistic means already proven. Already accepted. Already inside the boundary of what the world has agreed to allow.

Everything that matters was once not realistic.

The Soul Knows Before the Mind Allows

There is a part of a person — call it the soul, call it intuition, call it the deepest knowing — that perceives what is true before the mind has checked it against what is permitted.

It is the part that knows a relationship is wrong before you have assembled the rational argument. The part that feels the wrongness of a system before you can articulate what the wrongness is. The part that reaches toward a possibility before it has any evidence that the possibility is achievable.

This is not wishful thinking. It is a form of perception. A way of seeing that operates below the level of the practical filter — before the filter has had the chance to say but is it realistic?

The practical voice — once internalized — sits at the entrance to that perception and taxes every idea that tries to pass through. It demands proof of viability before it will allow the idea to fully form. It requires that the destination be visible before it will permit the journey to begin.

And in doing so it kills something. Not the desire — the desire persists, often for years, sometimes for a lifetime, as a quiet ache. But the connection to the desire. The willingness to take it seriously. The capacity to act from it before the world has confirmed that acting is reasonable.

That is what practicality kills.

Not the dream. The relationship with the dream.

The Internalized Voice

The most insidious thing about the practical voice is what happens after it moves inside.

When it was external — a parent, a teacher, a colleague, a culture — you could push back against it. You could disagree. You could feel the resistance and choose to cross it anyway.

Once it is internal, it no longer feels like an external constraint. It feels like your own judgment. Your own maturity. Your own honest assessment of what is and isn’t possible.

And so when the reaching stops — when the idea retreats before it has fully formed, when the dream is filed under nice but not realistic — it does not feel like suppression. It feels like wisdom.

This is the completion of the process. The world does not need to limit you anymore. You have learned to limit yourself. Efficiently. Quietly. With the full conviction that you are being sensible.

I have seen this in people of extraordinary talent. People who know, somewhere beneath the practical voice, that they are capable of something remarkable — and who have become so fluent in the language of their own limitation that they can produce a convincing practical argument against themselves in seconds.

It is one of the saddest things I know.

What the Radical Understands

The radical — in the deepest sense of that word — is the person who refused to let the practical voice become the final word.

Not because they are naive. Not because they don’t understand constraints. But because they understand something the practical voice never mentions:

The price of not reaching is also a price.

The price of radical is visible and immediate. The disruption, the risk, the discomfort, the possibility of failure. Everyone sees it.

The price of practical is invisible and accumulating. The slow dimming of what was once alive. The gradual narrowing of what feels possible. The person you were becoming, quietly set aside in favor of the person the world found acceptable.

Nobody sees that price while it is being paid.

Some people only see it at the end. Looking back at the distance between where they are and where they knew, once, they were trying to go.

It’s Difficult. That Is the Point.

Here is what I have come to believe.

It’s difficult is not a reason to stop.

It is proof that you are going somewhere worth going. If it were easy — if it were comfortable, if it fit neatly inside what is already accepted as realistic — you would already be there. Everybody would be there.

The difficulty is not the obstacle between you and the destination. The difficulty is the path to it. The obstacle is the way.

This is true in yoga. It is true in art. It is true in architecture — building and IT. It is true in any field where the work asks you to bring something genuinely new into being rather than reproduce what already exists.

The soul knows this. The practical voice does not.

And the practice — because it is a practice, ongoing, never completed — is learning to hear the soul’s knowing before the practical voice has had the chance to tax it into silence.

What This Has to Do With Architecture

The architect who has had their soul worn down by practicality designs practical systems.

Safe. Correct. Functional. Compliant with every constraint. Defensible in every review.

And somehow, despite all of that, not quite worth inhabiting. Not alive in the way that the best systems — like the best buildings — are alive. Not designed from a genuine vision of what the people inside them deserve. Designed, instead, from a careful negotiation with what is allowed.

The architect whose soul is intact designs differently.

Not without constraints. Not without practicality. But with something underneath the practical decisions that the practical decisions serve — a genuine vision of what could be, held with enough conviction to survive the inevitable pressure to make it smaller, safer, more realistic.

Christopher Alexander spent his life asking why some spaces feel alive and others feel dead. His answer, in the end, was about the quality of attention and care brought to the making. About whether the person who designed it was genuinely present — genuinely reaching toward something — or going through the motions of a process.

The soul is what makes the reaching possible.

Practicality, unchecked, is what makes it stop.

Practicality Kills the Soul was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every serious IT organization has a target architecture.

A vision of what the landscape should look like. Clean. Coherent. Designed for the future rather than inherited from the past. The diagram on the slide that shows where everything is going — the cloud migration completed, the legacy systems retired, the data model unified, the integration layer coherent.

And almost every organization lives at a comfortable distance from that target.

Not because the vision is wrong. Not because the people are incapable. But because the journey toward it requires paying a price that practicality keeps deferring.

This year the legacy system cannot be replaced — too expensive, too risky, too disruptive to the business. Next year the budget is committed elsewhere. The year after, there is a merger to absorb. The year after that, a new platform to evaluate.

The target architecture becomes a permanent horizon. Always visible. Never reached.

And something quiet but corrosive happens over time. The target stops being a destination and becomes a decoration. A vision that justifies the governance function without ever actually changing the landscape. A radical idea that has been made comfortable — and in being made comfortable, has been made inert.

Practicality Is Not the Enemy — But It Can Become the Prison

The practical constraints are real. Nobody serious denies that.

Legacy systems exist. Budgets are limited. Teams have finite capacity. Vendors have contracts. The organization built something three years ago that works, that people depend on, that carries irreplaceable institutional knowledge in its configuration and its data.

These are not excuses. They are facts.

But there is a moment — and it arrives gradually, almost invisibly — when legitimate constraints become a permanent justification for not moving. When the practical stops being a set of real obstacles to navigate and starts being the architecture of a comfortable prison.

The prison is not built from bad intentions. It is built from reasonable decisions, each of which made sense at the time. Each deferral was justified. Each compromise was defensible. Each “not this year” had a good reason behind it.

And yet the accumulation of all those reasonable decisions is an organization that cannot change. That knows where it needs to go and cannot get there. That has a target architecture it will never reach because the price of reaching it is always higher than the price of staying where it is.

Practicalities are not excuses. But they can become them.

The question is not whether the obstacles are real. They are. The question is whether you are navigating them — or living inside them.

The Rebel and the Radical

There are two kinds of architects who push back against this.

The rebel is against the legacy. Against the technical debt. Against the accumulated bad decisions of the past. This energy is real and often right. The rebel sees clearly what is wrong and is willing to say so.

But the rebel defines themselves by opposition. Their energy is reactive — it depends on the thing they are pushing against. Take away the legacy and the rebel has no direction. The rebel is against the prison without necessarily knowing what freedom looks like.

The radical is something different. And something deeper.

The radical is not primarily against anything. They are for something — a vision clear enough, coherent enough, and important enough that the price of reaching it becomes acceptable. Not invisible. Not painless. Acceptable.

The radical architect has looked at the distance between where the organization is and where it needs to be — and decided that the difficulty of the journey does not change the necessity of taking it.

They are willing to pay the price of breaking practicality. Not recklessly. Not without understanding what the price is. But with the clarity and the commitment that comes from knowing exactly what they are building toward and why it matters.

The rebel reacts. The radical builds.

Clarity as the Most Radical Act

Here is what makes the radical architect genuinely disruptive in most IT organizations.

It is not their technical knowledge. It is not their willingness to challenge decisions. It is not even their commitment to the target.

It is their clarity.

In a field that is deeply comfortable with ambiguity — with roadmaps that point in directions without specifying destinations, with principles that guide without constraining, with visions that inspire without demanding — being crystal clear is the most disruptive thing an architect can do.

Vagueness is comfortable. It accommodates everyone. It defers conflict. It allows every stakeholder to see their preferred future in the architecture vision without forcing any of them to confront the distance between that vision and their current decisions.

Vague architecture is not architecture. It is a conversation that never forces a decision.

The radical architect has clarity. About what the target is. About why it matters. About what it will cost and what it will take. About what has to stop in order for what needs to start to begin.

And that clarity creates discomfort — because it makes the distance between where the organization is and where it needs to be impossible to ignore. It turns a comfortable horizon into an urgent destination. It forces a choice that ambiguity was successfully deferring.

Crystal clear. Impractical. But clear.

That is the radical position.

The Price of Radical

Radicallity has a price. It is worth naming honestly.

The radical architect will be told they are not being realistic. That they don’t understand the constraints. That their vision is theoretically sound but practically impossible. That the organization is not ready. That the timing is wrong. That there is a better moment coming — just around the corner, just after the next project, just when the conditions are right.

These objections are the practical defense. And they are sophisticated — because they are almost always partially true. The timing is never perfect. The organization is never fully ready. The constraints are never entirely absent.

But here is what the practical defense never says out loud: there is also a price for not being radical. For another year of deferral. For another round of workarounds. For another layer of complexity added to a landscape that is already too complex. For the slow, compounding cost of an architecture that cannot change at the speed the business needs.

The price of radical is visible and immediate. The price of practical is invisible and accumulating.

Most organizations optimize for the visible cost and ignore the accumulating one — until the day the accumulating cost becomes a crisis. And then the radicallity that was “not the right moment” becomes an emergency that costs ten times as much and happens under far worse conditions.

The radical architect understands this calculus. And is willing to have the conversation — clearly, honestly, without drama — about both prices.

What Radical Looks Like in Practice

Radical architecture is not recklessness. It is not the wholesale rejection of constraints or the insistence on perfection before progress.

It is the refusal to let practicality become permanence.

It looks like a target architecture that is specific enough to make decisions against — not a direction but a destination. Not “more cloud-native” but a defined end state that every current decision either moves toward or moves away from.

It looks like the willingness to name, in a room full of stakeholders, the things that have to stop. The integrations that have to be retired. The platforms that have to be replaced. The patterns that have to be broken. Not eventually. On a timeline with a commitment behind it.

It looks like treating the target architecture not as a slide that justifies the governance function but as a contract with the future — one that current decisions are either honoring or violating.

It looks like clarity about the cost of staying where you are — because the radical case is not only “here is where we need to go.” It is also “here is what it is costing us not to.”

And it looks like the patience and the persistence to hold that clarity through the cycles of deferral, the changes of leadership, the budget constraints, and the reasonable-sounding objections — without letting the vision be slowly diluted into something comfortable enough to be inert.

The Obstacle Is the Way

There is a temptation, when the practical obstacles accumulate, to treat them as signals. Evidence that the vision is wrong, or premature, or insufficiently sensitive to the realities of the organization.

Sometimes that is true. The vision should be tested against reality. The radical architect is not immune to being wrong.

But often the difficulty is not a signal that the direction is wrong. It is proof that the direction is right — that it is pointing somewhere genuinely different from where the organization currently is. If the target were easy to reach, the organization would already be there.

The obstacle is the way.

Not the thing to be eliminated before the journey can begin. The journey itself. The price that radical asks you to pay — not as punishment, but as evidence of commitment.

The architect who waits for the obstacles to clear before moving toward the target will wait forever. The obstacles are not temporary conditions on the way to a clear path. They are the permanent texture of the work.

The radical architect moves through them. With clarity about the destination. With honesty about the cost. With the patience to hold the vision through the resistance — and the courage to keep naming, clearly and without apology, what the target is and why it matters.

That is what it means to be radical in IT architecture.

Not against the legacy. For what comes after it.

Radical Clarity — Why the Most Disruptive Thing an IT Architect Can Do Is Be Crystal Clear was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are trained to find solutions.

That is, if you think about it, almost entirely what school is. A problem appears. There is a correct answer. The reward goes to the student who finds it fastest. The discomfort of not knowing is something to be eliminated as quickly as possible.

Twelve, sixteen, twenty years of that training. It goes deep.

So deep that most of us carry it into every professional situation without noticing. A problem appears in a meeting. The brain immediately starts generating solutions. The discomfort of sitting with the unknown triggers something almost physical — an urgency to reach for an answer. Any answer. One that makes the discomfort stop.

We have been so thoroughly trained to solve problems that we have forgotten how to be with them.

And that, I would argue, is one of the most expensive habits in architecture and software development today.

The Problem Is Not the Enemy

The first shift is a simple one. But it changes everything.

The problem is not the enemy.

School taught us otherwise. The problem is the obstacle between where we are and the correct answer. It exists to be overcome, eliminated, solved. The faster the better.

But this framing — problem as enemy — leads directly to a particular kind of blindness. It makes us reach for solutions before we have truly understood what we are dealing with. It makes us impatient with complexity, intolerant of ambiguity, and allergic to the kind of slow, patient inquiry that genuine understanding requires.

The designer, the architect, the truly creative practitioner — they relate to problems differently.

The problem is not the enemy. The problem is the teacher.

It contains, if you look carefully enough and without the distortion of your existing solutions, the shape of what it needs. The problem is always trying to tell you something. The question is whether you are willing to listen long enough to hear it.

The Logic the Problem Presents

Here is something subtler. And more important.

Every problem arrives pre-packaged with its own apparent logic.

This is a cost problem — therefore the solution is to reduce cost. This is a speed problem — therefore the solution is to go faster. This is an integration problem — therefore the solution is to integrate. This is a legacy system problem — therefore the solution is to replace the legacy system.

The problem presents its logic. And the logic seems reasonable. Obvious, even. And so we follow it — directly into the solution space the problem has already prepared for us. Where the conventional answers live. Where everyone who faced a similar problem has already been. Where the familiar tools are waiting.

But that logic is often the problem’s disguise.

The presenting logic is not always the real logic. The problem as stated is not always the problem that needs solving. The solution space the problem invites you into is not always the solution space that contains the true answer.

To doubt the logic presented by the problem — to ask whether the problem is actually what it appears to be, whether the framing is accurate, whether the logic is worth following — is one of the core skills of true creativity.

It is also one of the hardest. Because the logic feels obvious. And obvious things are difficult to question.

Falling In Love With the Problem

There is another way to relate to problems. One that produces better outcomes and, I would argue, a richer experience of the work itself.

Fall in love with the problem.

Not with the solution. Not with your idea for the solution. With the problem itself — its texture, its contradictions, its history, its human dimensions, the reasons it exists and the reasons it persists.

The architect who falls in love with the brief — who asks every question, who sits with the contradiction, who refuses the first obvious answer and keeps looking — finds something the solution-seeker never finds.

Not a correct answer. A true answer. One that emerges from the nature of the problem itself rather than being imposed on top of it.

This is what distinguishes the work that feels inevitable — that seems, in retrospect, like it could not have been any other way — from the work that feels applied. Correct but external. A solution placed on top of a problem rather than grown from within it.

Fallingwater does not feel like a solution to the problem of building a house near a waterfall. It feels like what the site was always trying to become. That is what falling in love with the problem produces. Not the fastest answer. The truest one.

We Jump Too Soon

In architecture and software development, we jump to solutions before we understand the problem.

This is not a character flaw. It is a trained reflex — accelerated by the cultures of both fields, which celebrate speed, decisiveness, and the bias toward action.

Discovery phases are rushed or skipped. Requirements are treated as problems already half-solved — a list of answers waiting for implementation rather than a starting point for inquiry. The architecture conversation begins with technology before it begins with need. The solution is in the room before the problem has been fully heard.

And the cost is enormous.

Not just in rework. Not just in technical debt. In the deeper, quieter failure of building something technically correct that doesn’t solve what actually needed solving. Systems that work but don’t serve. Architectures that are coherent on the diagram but alien to the people who have to live inside them.

The problem was never fully understood. The solution was reached too soon. And by the time that becomes clear, the cost of going back is higher than the cost of living with something wrong.

Sitting With Discomfort

The skill that school never taught — and that the best architects, designers, and engineers have somehow developed anyway — is the ability to sit with the discomfort of not knowing.

To resist the pull toward solution. To stay in the question. To let the problem reveal itself rather than forcing it into a familiar shape.

This is harder than it sounds. The discomfort is real. The pressure — from clients, from timelines, from colleagues, from the part of your own brain that was trained in school — is real. The relief that comes from having an answer, any answer, is seductive.

But the practitioner who can stay in the problem longer than is comfortable — who can tolerate ambiguity, sit with contradiction, and resist the premature closure of a good-sounding solution — consistently produces better work than the one who reaches for the answer first.

Not because slow is better than fast. But because understanding is better than assumption.

The obstacle is the way. Not the thing to be overcome as quickly as possible — the thing to be explored, understood, inhabited.

Letting go of conventional ideas — including the conventional idea that problems exist to be solved quickly — is where the real work begins.

What This Looks Like in Practice

Falling in love with the problem is not a passive state. It is an active discipline.

It means asking more questions than you think are necessary — and then asking more.

It means being genuinely curious about why the problem exists, not just what it is. Problems have histories. They have political dimensions, cultural dimensions, human dimensions. Understanding those does not slow the solution down. It changes what the solution needs to be.

It means doubting the framing. Every problem arrives in a frame — a set of assumptions about what kind of problem it is, what solution space it belongs to, what constraints are real. Good architects question the frame before they accept it.

It means being willing to restate the problem. Often the most valuable contribution an architect can make — before a single technical decision — is to say: I don’t think this is the problem. I think the problem is this.

And it means developing a tolerance for the discomfort of not knowing. Which, like most important skills, improves with practice and intention.

The Most Important Moment in Any Project

There is a moment in every project — usually early, often rushed past — when the problem is still open. When the solution space has not yet been decided. When the frame is still available for questioning.

That moment is the most important moment in the project.

What happens in it — how deeply the problem is understood, how seriously the logic is questioned, how honestly the framing is examined — determines more about the quality of the outcome than any technical decision that follows.

Most projects invest the least attention in that moment. Because it is uncomfortable. Because it does not feel like progress. Because the client wants to see something, the timeline is already running, and the brain wants relief from the uncertainty.

But the architect who protects that moment — who insists on understanding before designing, on questioning before deciding, on sitting with the problem long enough for it to reveal what it actually needs — is doing the most important work in the project.

Falling In Love With the Problem — The Most Underrated Skill in Architecture and Design was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Martin Fowler asked the question twenty years ago: who needs an architect?

His answer was elegant. Architecture, he argued, is fundamentally about irreversibility. The decisions that are expensive to reverse. The load-bearing walls of a digital system — invisible until you try to move them. And the architect is the person who identifies those decisions and ensures they are made with sufficient care, foresight, and understanding of consequence.

It is one of the most clarifying ideas in software architecture. And it was built on an assumption so obvious at the time that nobody needed to state it.

Change is expensive.

That assumption is dissolving. And it raises a question the field has not yet properly answered.

The Collapsing Cost of Change

Low code platforms. No code tools. AI-assisted development. They are all pushing in the same direction — toward a world where the cost of building something approaches the cost of deciding to build it.

In some contexts that crossing point has already arrived. An AI agent can refactor an application in hours that would have taken a team weeks. A low code platform can restructure a workflow in an afternoon that would once have required a sprint. The friction between idea and implementation — which was always the economic foundation of architectural thinking — is disappearing.

If Fowler defined architecture as things that are hard to change — what happens to architecture when nothing is hard to change?

Luis Barragán and the Moving Walls

The Mexican architect Luis Barragán had an unusual practice.

He moved walls during construction.

Not because he was indecisive. Because he was seeing. He needed to experience the space as it was becoming — to stand inside the emerging reality and let it teach him things the drawing on paper never could. The physical presence of the walls, the actual quality of the light, the way the proportions felt in the body rather than the mind — these revealed things that no amount of upfront design could have predicted.

Barragán’s architecture was not designed and then built. It was designed through building. The making itself was part of the thinking.

This is what Christopher Alexander called unfolding — the idea that living structure cannot be imposed from a masterplan but must emerge through a process of continuous, attentive response to what is actually there. Each step of the process preserves and extends the wholeness of what exists. The design does not precede the building. The design and the building are a single, continuous act.

Low code and AI are making every software project more like Barragán’s construction site.

You can move the walls. You can see what you are building as it emerges, respond to what it tells you, change direction when the reality reveals something the model didn’t.

Which sounds, at first, like the architect’s dream. Total freedom to design through making.

But it raises a question that Barragán never had to answer — because he was working alone, or with a small team, on a single building.

What happens when hundreds of people are all moving walls simultaneously?

The New Irreversibilities

Here is the insight I think the field is missing.

When development costs drop, the technical irreversibilities that Fowler described become less significant. You can refactor the module structure. You can restructure the data model. You can change the integration pattern. These things become progressively cheaper as the tools improve.

But a different category of irreversibility barely changes at all.

Human irreversibility.

People form habits around systems. Deeply, stubbornly, often unconsciously. A workflow that has been done a particular way for two years is not easily changed — not because the system cannot be changed, but because the people using it have internalized its logic. It has become part of how they think about their work.

Organizations build processes around platforms. Departments structure themselves around the systems they use. Culture calcifies around tools in ways that are genuinely, stubbornly hard to reverse — regardless of how easy the underlying technology is to modify.

Data accumulates meaning over time. The decisions made about data structures in the first months of a system’s life shape what can be known and asked for years afterwards. Not because the structure cannot be changed — but because the data that has accumulated inside it carries the fingerprint of every decision ever made.

Trust is perhaps the most irreversible thing of all. A system that fails people, that loses their data, that behaves in ways they did not expect — creates a relationship with its users that is almost impossible to undo, regardless of how thoroughly the technology is rebuilt.

These irreversibilities were always present. But they were hidden behind the more visible and more discussed technical irreversibilities. As the technical ones dissolve, the human ones become the dominant challenge.

And they require a completely different kind of architectural thinking.

What the Architect Becomes

If the architect of the industrial software era was primarily a manager of technical complexity — identifying load-bearing decisions, containing irreversibility, designing for change — then the architect of the low code and AI era is something different.

Not less. More.

A guardian of coherence in an environment where the ease of change makes incoherence the default. When everyone can move walls, someone needs to hold the vision of what the building is becoming. Not to slow things down — to ensure that the accumulation of fast, cheap, individually reasonable decisions adds up to something whole rather than something fractured.

A reader of human systems as much as technical ones. The irreversibilities that matter now are organizational, cultural, behavioral. Understanding them requires the ability to see how people actually work, how organizations actually behave, how culture actually forms around the systems people use every day. This is not a technical skill. It is a deeply human one.

A designer of environments for others to build in. In a low code platform, the architect is not primarily building the system. They are building the structure inside which others build. The quality of that structure — its clarity, its guardrails, its coherence — determines the quality of everything that gets built inside it. This is closer to urban planning than software engineering. The architect designs the city. The citizens build their lives inside it.

A keeper of the why. In a world where building is fast and cheap, the memory of why decisions were made becomes precious and fragile. Teams change. Context is lost. The system accumulates the residue of a thousand decisions whose reasoning has evaporated. The architect holds that memory — not as a bureaucrat of documentation, but as someone who understands deeply enough to reconstruct the reasoning when the documentation is gone.

The Question Beneath the Question

There is a deeper question underneath all of this that the industry will need to confront.

When building is cheap enough — when AI can construct a functioning application from a description, when no code tools put development in the hands of anyone with a browser — the question is no longer can this be built.

It is should this be built. And what will it do to the people inside it.

That question has always been the true domain of architecture. In building, it is the question that separates the architect from the engineer — the structural engineer makes sure it stands up, the architect makes sure it is worth standing in. The question was always there in software too, but it was crowded out by the sheer difficulty of the technical challenges.

As the technical difficulty decreases, the human question moves to the centre.

Christopher Alexander spent his career asking why some spaces feel alive and others feel dead — even when they are built to identical specifications, with identical materials, following identical patterns. His answer, developed over fifty years, was that living structure emerges not from the correctness of the decisions but from the quality of attention brought to the process of making. From genuine care for the life the structure will contain.

That quality of attention is what the architect of the AI era needs to bring.

Not primarily to the technical decisions — the tools are increasingly capable of handling those. But to the human ones. To the question of what is being built, for whom, and what it will mean for the people who will live inside it.

The Most Important Question in Architecture

Vitruvius wrote two thousand years ago that architecture must be solid, useful, and beautiful.

The tools of our era are making solid easier than it has ever been. Useful has always been achievable. Beautiful — in the deepest sense, the sense Alexander meant, the quality of aliveness — remains as rare and as demanding as it has always been.

Perhaps more demanding now. Because the barrier to building has never been lower. Which means the barrier to building something without soul, without coherence, without genuine care for the human life inside it — has never been lower either.

Who needs an architect?

Anyone who wants to build something worth inhabiting.

The answer has not changed. Only the reasons have.

Who Needs an Architect When Nothing Is Hard to Change? was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Art of the Commission — Why the Shift from Execution to Governance Is Really About Learning to Be a Good Client

In the Netherlands, the built environment gives an award that most countries don’t have a name for.

Not just for the best building. For the best opdrachtgever.

The best commissioner. The person or organization who created the conditions in which great architecture could happen.

The award exists because the Dutch built environment understands something that most organizations — in construction, in design, and especially in IT — have not yet fully reckoned with:

The quality of what gets made is inseparable from the quality of the person who commissioned it.

There is no English word for opdrachtgeverschap. The art and skill of commissioning. The closest equivalents — patronage, client leadership, project ownership — don’t quite reach it. And that linguistic gap is itself significant. A skill without a name is a skill without a culture around it. A skill that gets underestimated, underdeveloped, and undervalued.

That is precisely what has happened in IT.

And it is about to matter more than it ever has before.

The Best Work Comes From the Best Clients

Anyone who has worked in a creative field knows this truth, even if they rarely say it out loud.

The best design projects have the best opdrachtgevers.

Not the most agreeable clients. Not the ones who approve everything and ask for nothing. The ones who arrive with genuine clarity about what they are trying to achieve and why it matters. Who engage seriously with the work rather than delegating it entirely. Who trust the craft without abdicating the direction. Who can evaluate what comes back with real judgment rather than just checking boxes against a list of requirements.

The Guggenheim Bilbao did not happen because Frank Gehry is talented. It happened because someone commissioned it with clarity, courage, and genuine partnership. The brief was worthy of the architect. The client was equal to the vision.

Bad clients produce bad work regardless of the talent they hire. The brief is wrong, the constraints are invented, the feedback is arbitrary, the goalposts move. The agency delivers something technically correct and humanly absent — because the commission never gave them anything real to work with.

Good clients unlock work that surprises even the people who made it. Because the brief was clear enough to aim at, and open enough to allow the craft to find something the client couldn’t have specified in advance.

This dynamic is not unique to architecture or design. It operates in every field where thinking and making are separated. Where one party commissions and another delivers.

Which is to say — it operates in IT. It always has. Most organizations just haven’t noticed yet.

The Safety Net We Are About to Lose

For most of IT’s history, the consequences of poor commissioning were absorbed by proximity.

Architects and developers worked alongside each other. Business stakeholders and delivery teams were in the same building, often the same room. When the brief was incomplete — and it almost always was — the gaps were filled in real time. Decisions were made in standups. Architecture evolved through conversation. The course corrections happened continuously, naturally, invisibly.

The organization didn’t need to be a good opdrachtgever because it was always present during the making. The execution team compensated for the commissioning team’s limitations. Continuously. Without anyone fully noticing that this was happening.

This is the safety net that outsourcing begins to remove.

When execution moves to a sourcing partner, the proximity disappears. The brief can no longer be completed in real time. The gaps can no longer be filled through conversation. What was implicit must become explicit. What was assumed must be stated. What was adjusted continuously must be decided upfront — or managed through a formal handoff process that is slower, more expensive, and more fragile than the informal adjustments it replaces.

To succeed, organizations need to develop something different. The ability to think clearly before the work begins. To brief precisely. To evaluate rigorously. To stay in genuine partnership with the maker — present enough to guide, trusting enough to let the craft do its work.

They develop, in other words, opdrachtgeverschap.

The Shift From Execution to Governance

What is happening when IT organizations outsource— and will accelerate significantly in the years ahead — is a fundamental inversion of the model.

The traditional IT organization was built around execution. Its primary capability was building and running things. Developers, testers, delivery managers, project leads. Governance and architecture existed, but often as overhead around the real work.

As execution moves outside — to sourcing partners today, to AI agents tomorrow — what remains inside is a completely different kind of organization. One whose primary capability is not building but commissioning. Not executing but directing. Not making but seeing clearly enough to guide what gets made.

This organization needs:

Strategy — a genuine understanding of what needs to be built and why. Not a list of requirements but a point of view about where the organization is going and what role technology plays in getting there.

Architecture — the coherent vision of the whole that prevents a thousand individually reasonable decisions from adding up to something incoherent. The guardian of wholeness in a world where execution happens at speed, outside the building, without continuous oversight.

Business alignment — the deep, ongoing relationship with the organization’s actual needs. Not what the business said it wanted six months ago when the requirements were written. What it needs now, as context shifts and understanding deepens.

Governance — the ability to evaluate what comes back. To check outputs not just for technical correctness but for coherence, for alignment with intent, for the human experience they will create. To improve what is returned rather than simply accepting or rejecting it.

Preparation — the unglamorous, undervalued, absolutely essential work of making the brief good enough. Complete enough. Clear enough on the why, open enough on the how, precise enough on the constraints, honest enough about the uncertainties.

This is not a smaller version of the old execution organization. It is a different organization with a different skill set, a different culture, and a different definition of what good work looks like.

The transition is hard. Not because the technical skills are difficult to acquire — but because the identity shift is profound. People who built their careers on execution, on being in the room, on the satisfaction of making things — are being asked to step back from the making and invest in the commissioning.

That feels like loss before it feels like growth.

What AI Changes — And What It Doesn’t

The sourcing partner relationship is, in many ways, the rehearsal for what comes next.

AI agents will execute faster, cheaper, and more tirelessly than any partner. They will write code, design interfaces, structure data, build integrations — at a speed and scale that changes the economics of software development entirely.

But they will need direction. Clear, precise, thoughtful direction. A brief that is complete enough to work from. Governance that is rigorous enough to catch what the agent cannot catch about itself. An opdrachtgever who understands what is being built and why — and can evaluate what comes back with genuine judgment.

The quality of the AI agent’s output will be, almost entirely, a function of the quality of the commission.

This is not a new problem. It is the oldest problem in creative collaboration — made newly urgent by the scale and speed at which AI can execute a bad brief.

The organizations building governance capability now — through the hard experience of working with sourcing partners, developing the discipline of preparation and handoff, learning what good commissioning actually requires — will be ready for that world.

The organizations waiting for AI to arrive before they think about governance will find themselves exactly where every organization ends up without an opdrachtgever:

With a great deal of output. And no idea whether any of it is what they actually needed.

What Good Opdrachtgeverschap Looks Like

It is worth being specific, because the skill is so rarely named that it is rarely developed consciously.

Clear on the why, open on the how. The good opdrachtgever knows what problem they are solving and what success looks like. They do not specify the solution — that is the craft of the maker. They specify the intent. The constraints that are real. The experience they want to create.

Trusts the craft without abdicating the direction. The worst clients micromanage the making and disappear from the meaning. The best clients hold the meaning firmly and give the making room to breathe.

Evaluates with genuine judgment. Not against a checklist. Against the intent. Does this solve the problem? Does it create the experience we wanted? Does it hold the coherence of the whole?

Stays in genuine partnership. The commission is not a transaction. It is a relationship. The opdrachtgever who disappears after the brief and reappears only to evaluate the output is not a partner — they are a client in the worst sense of the word. Presence, engagement, and genuine interest in the work are not optional extras. They are part of what makes the work good.

Prepares seriously. This is perhaps the hardest shift for execution-oriented organizations. Preparation feels like overhead. It feels like delay. It feels like work that doesn’t produce anything.

It produces everything.

The quality of the brief is the quality of the output. The time invested in preparation is the time saved in correction, rework, misalignment, and the slow, expensive discovery that what got built is not what was needed.

The Architect as Opdrachtgever

There is one more connection worth making.

The shift from execution to governance is, in many ways, the shift toward architecture — in the fullest sense of that word.

The architect has always been an opdrachtgever of a particular kind. Not the client who commissions the building — but the professional who translates the client’s intent into a brief precise enough for the builder to work from, and who governs the making closely enough to ensure the vision survives contact with reality.

The IT architect of the governance era does the same thing. They translate business intent into architectural direction. They brief the execution — whether partner or AI agent — clearly enough to work from. They govern the output rigorously enough to catch the drift before it becomes the architecture.

This is why architecture becomes more important as execution moves outside. Not less.

And it is why the skill of opdrachtgeverschap — the art of the commission — is not a soft skill or a project management capability or a nice-to-have.

It is the core competence of the organization that has stopped executing and started governing.

The Dutch built environment understood this well enough to give it an award.

Perhaps IT is ready to take it seriously too.

The Art of the Commission — Why the Shift from Execution to Governance Is Really About Learning to… was originally published in Architecture Thinking Notebook on Medium, where people are continuing the conversation by highlighting and responding to this story.