When Medieval Cathedrals Had Better Architecture Than Modern IT

Foundations

There was a time when civilisation built cathedrals.

Construction did not follow quarterly planning cycles, productivity dashboards, or transformation roadmaps. Builders accepted long horizons, difficult constraints, and continuity extending beyond individual careers.

They emerged from coherent vision, accumulated craftsmanship, and long-term thinking. Entire generations worked on the same structure while understanding they would never personally see completion. Stone cutters, engineers, glass workers, carpenters, and architects aligned around continuity rather than short-term optimisation.

A cathedral carried intent. Every addition respected the structure already standing. Every modification considered weight distribution, durability, future maintenance, and how the whole system behaved once assembled. Builders understood that complexity without coherence eventually collapsed under its own mass.

Modern enterprise software presents almost the opposite picture.

We possess computing power beyond anything imagined by the engineers who landed humans on the moon. We automate infrastructure in seconds. We provision globally distributed systems from a laptop. We can simulate, deploy, rollback, observe, and scale at planetary levels.

Yet many organisations struggle to preserve architectural continuity for more than eighteen months.

The average enterprise platform now resembles a construction site where every new foreman arrives with different blueprints, renames the rooms, replaces half the tools, introduces a new governance model, schedules a transformation workshop, and leaves before the consequences appear.

One quarter later, another leader arrives to explain that the previous architecture lacked strategic vision and that true agility requires rebuilding the plumbing again.

Some companies now modernise the same authentication flow with the same enthusiasm medieval kingdoms reserved for territorial wars.

Nobody entirely understands why the login page depends on seventeen services, three feature flags, two API gateways, a Kafka topic, and a machine-learning recommendation engine.

Despite this, discussions still drift toward alignment workshops, governance reviews, and communication rituals rather than structural simplification.

Medieval builders worked with primitive tools and incomplete scientific understanding, yet managed to create structures surviving centuries. Modern IT teams, surrounded by automation, frameworks, AI copilots, observability stacks, and infinite cloud elasticity, regularly produce systems nobody fully understands after three years.

The cathedral builders at least knew where the stones were.

Meanwhile modern organisations proudly maintain distributed architectures where nobody can explain the complete request flow without opening twelve dashboards, three Confluence pages, and summoning an engineer who resigned eight months ago.

Layers

Part of the problem comes from how modern organisations perceive software.

Cathedrals emerged from the assumption that foundations mattered more than speed. Enterprise software often follows the opposite instinct, treating speed as compensation for weak foundations. In practice, this approach merely delays structural failure until dependencies accumulate beyond visibility.

A medieval architect understood load-bearing walls. Modern organisations sometimes treat architecture as an inconvenience slowing feature delivery. Teams receive incentives for visible additions rather than systemic coherence. Temporary solutions survive indefinitely because removing them generates less political visibility than introducing something new.

Layers therefore accumulate. Temporary migrations become permanent infrastructure. Emergency integrations evolve into critical dependencies. Tactical workarounds slowly harden into organisational doctrine.

Nobody removes anything because every layer now supports another fragile layer above it.

Entire teams now dedicate themselves to preserving systems officially described as temporary in 2019.

Enterprise IT may have perfected one particular capability: turning provisional decisions into permanent institutions faster than most governments.

Eventually the platform reaches a strange state where teams no longer build systems but negotiate with ruins.

This explains why so many enterprise environments feel exhausting despite extraordinary tooling. It comes from navigating incoherent systems carrying years of accumulated contradictions.

Enterprise software eventually starts behaving like an ancient city built on top of itself, with every generation adding another layer without fully removing the previous one.

Old roads remain underneath new roads. Forgotten tunnels continue supporting critical flows nobody notices until collapse begins. Systems accumulate hidden dependencies, undocumented assumptions, and operational folklore passed orally between engineers like medieval trade secrets.

The platform therefore continues expanding around artefacts nobody dares remove because nobody entirely understands what still depends on them.

The contradictions become visible everywhere:

• duplicated platforms
• conflicting ownership models
• overlapping governance
• half-finished transformations
• reactive architecture
• metrics disconnected from customer outcomes
• dependencies nobody dares challenge

At some point, organisations stop engineering and start compensating for unclear interfaces, organisational fragmentation, and systems nobody fully trusts anymore.

This explains an increasingly common modern ritual: the meeting organised to prepare the meeting required before approving the migration intended to simplify the process introduced by the previous simplification initiative.

This also explains why genuinely senior engineers often sound conservative. The posture rarely comes from resistance to innovation and far more often from understanding the operational cost of incoherence.

A cathedral builder could not afford fashionable instability every quarter. Neither can large-scale software systems.

Strong engineering cultures therefore tend to share characteristics with historical craftsmanship:

• respect for foundations
• continuity of intent
• careful interfaces
• disciplined evolution
• removal of unnecessary complexity
• deep understanding of system behaviour over time

These organisations value disciplined evolution rather than accidental complexity disguised as innovation.

Permanence

The most interesting contrast may however sit elsewhere.

Cathedrals were built by people expecting the structure to outlive them, while many enterprise environments optimise for the opposite.

Many systems now evolve under short leadership cycles, quarterly incentives, reorganisation patterns, and delivery pressure disconnected from operational longevity. Teams optimise for surviving the roadmap rather than preserving coherence.

Cathedral builders probably would have struggled with modern delivery culture. One can easily imagine a bishop interrupting construction every six months to announce a strategic pivot toward modular chapels, decentralised arches, and a stronger emphasis on localised worship enablement.

A steering committee would then spend three years debating flying buttress adoption while the roof collapsed in production.

The result appears everywhere: five observability platforms, three authentication systems, seven partially completed migrations, microservices splitting faster than ownership maturity, and roadmaps promising simplification while complexity compounds underneath.

Perhaps the most revealing symptom appears in organisations requiring dozens of synchronisation meetings simply to compensate for systems that no longer communicate clearly through their architecture.

Alignment

Cathedrals encoded alignment directly into the structure itself. Geometry carried meaning and the physical layout communicated intent.

Builders understood where forces travelled, how pieces interacted, and which constraints governed the whole structure. Coordination therefore emerged naturally from the architecture.

Modern organisations increasingly attempt to replace structural clarity with process overhead. When systems stop communicating clearly through their interfaces, organisations compensate socially.

The response usually follows a familiar pattern: more meetings, more alignment rituals, more reporting layers, more coordination groups, and more dashboards explaining why the previous dashboards failed to improve visibility.

The architecture no longer embeds clarity, so humans continuously reconstruct missing coherence through conversation.

At some point, entire departments exist mainly to coordinate the consequences of insufficient structural integrity.

This may represent one of the strangest regressions of modern engineering. We created extraordinary computational capability while progressively losing the ability to preserve systemic clarity over time.

That trade rarely scales because good architecture reduces coordination, while fragile architecture industrialises it.

Perhaps this explains why so many engineers secretly admire old infrastructure, railways, aircraft, bridges, mechanical watches, or historical industrial systems. The attraction rarely comes from rejecting modernity and far more often from recognising an older engineering philosophy where coherence mattered more than presentation.

• A bridge did not require six steering committees to confirm gravity alignment.
• A railway system could not survive through optimistic reporting.
• An aircraft designer could not compensate for structural weakness with roadmap storytelling.

Those industries understood something modern enterprise environments often forget. Reality eventually audits every system. Physics does not negotiate, customers do not care about internal transformation programmes, and production traffic ignores governance slides.

A civilisation that understood this produced systems designed for continuity, whereas modern IT too often produces systems designed for survivable quarterly narratives.

Ironically, the industry claiming to move fastest often struggles the most to build anything capable of remaining coherent over time.

We built infinitely scalable infrastructure and then used it to recreate organisational confusion at planetary scale.

The medieval builders, armed with ropes, candles, primitive cranes, and incomplete mathematics, somehow managed to produce structures with greater architectural continuity than organisations running twelve agile transformation programmes simultaneously.

Medieval builders would probably find this deeply confusing. Humanity increased its computational power beyond imagination, yet somewhere along the way many organisations lost the ability to preserve coherence, continuity, and structural discipline. Civilisation progressed technically while often regressing architecturally.

Conclusion

Yet the comparison also carries something strangely encouraging.

Cathedrals did not emerge from magic technologies, unlimited budgets, or perfect methodologies. They emerged from clarity of purpose, respect for constraints, patient craftsmanship, and the understanding that coherent systems require continuity.

Modern engineering still possesses those capabilities when organisations allow them to surface.

One occasionally encounters teams simplifying instead of accumulating, removing dependencies instead of celebrating them, protecting foundations instead of endlessly repainting interfaces, and treating architecture as a long-term responsibility rather than a quarterly narrative.

Those environments usually feel different almost immediately, with fewer coordination rituals, less theatre, cleaner interfaces, faster decisions, and greater trust between people because the system itself communicates clearly.

The irony perhaps sits there.

The industry often searches for salvation through more tooling, more frameworks, more governance, and more transformation layers, while many of the answers already existed centuries ago.

The underlying principles remain surprisingly simple: build structures people can understand, preserve coherence, respect foundations, and remove unnecessary complexity before it fossilises.

Perhaps most importantly, organisations should once again build systems intended to remain standing after the current roadmap disappears.