A Thought Experiment: Life in the ideal IT Landscape
- Claas
- Dec 18, 2025
- 5 min read
Christmas is approaching. Wishes are made.
Imagine, just for a moment, that you were granted one. Not a new tool, not additional budget, not another transformation program. Just a single, unrealistic privilege: the ability to redesign your entire IT landscape instantly.
No legacy systems.
No migration effort.
No organisational resistance.
No contractual lock-in.
With one decision, the landscape is replaced and put into operation. Perfectly. Immediately. This is a deliberately unrealistic thought experiment. Its value lies precisely in removing the usual explanations. If problems still appear, they cannot be attributed to history, execution or technical debt. They must be structural.
Now imagine what this ideal IT landscape would look like.
The ideal under static assumptions
In a world without change, the answer is surprisingly clear. Shared data models. Real-time integrations. Highly connected systems. Minimal redundancy. Global consistency. Information flows instantly, systems operate on a single version of truth and coordination overhead is low.
Under these assumptions, such a landscape would be close to perfect. Efficient. Elegant. Economical. It minimises friction and avoids duplication. It replaces negotiation with synchronisation.
The problem is not that this vision is wrong. The problem is that the conditions it requires never exist.
The cost of optimising for a static world
The moment change is introduced, the internal logic of the ideal landscape shifts. The properties that make it efficient under static assumptions do not disappear.They simply begin to produce different effects.
Shared data models, real-time integration and high connectivity enforce alignment by design. Under stable conditions, this alignment eliminates redundancy and coordination effort. Decisions are encoded once and applied everywhere. Synchronisation replaces negotiation.
Once assumptions begin to move, however, alignment no longer happens once. It must be maintained continuously. Every shared structure becomes a point of coordination. A change that would otherwise remain local now requires system-wide agreement. Not because the design is flawed, but because coherence is the primary optimisation goal. The system does exactly what it was built to do: it keeps everything consistent.
The cost emerges because consistency under change is not a technical problem, but a coordination problem. Each adjustment must be reflected everywhere, at the same time, under the same interpretation. Variation is no longer absorbed locally. It must be resolved globally.
In a static world, tight coupling reduces effort by enforcing coherence once. In a dynamic world, the same coupling increases effort by enforcing coherence continuously. This is the structural trade-off of the perfect landscape. The more precisely it is aligned, the more sensitive it becomes to deviation. The work shifts from execution to synchronisation. From building systems to aligning decisions.
This is why modern IT landscapes can appear both highly advanced and increasingly difficult to adapt. They are not overengineered. They are over-aligned. Optimised for consistency in an environment that rarely stays still.
Why change is not the exception
In large organisations, change is not an anomaly. It is the baseline. Regulatory requirements evolve. Business models shift. Mergers introduce new systems. Vendors change platforms. New technologies introduce new decision points. AI does not simply automate tasks, it redistributes judgement across systems and processes.
Designing IT landscapes as if stability were the norm is no longer realistic. The certainty of change must be treated as a first-order design constraint.
Once that assumption is accepted, the criteria for what constitutes an “ideal” setup change fundamentally.
Designing under certainty of change
Under constant change, architectural perfection becomes dangerous.
The more globally consistent a system is, the more expensive it becomes to modify. The more real-time dependencies exist, the harder it is to isolate impact. The more logic is shared, the more coordination is required for even small adjustments.
The question therefore shifts. It is no longer how to eliminate redundancy, but where redundancy is necessary. Not how to integrate everything, but what must remain local.
Not how to maximise efficiency, but how to limit the blast radius of change.
These are not purely technical decisions. They are organisational ones, because they determine how much coordination, negotiation and risk the organisation absorbs over time.
A different definition of “Ideal”
The thought experiment does not suggest that the ideal IT landscape is meaningless. It suggests that it is misleading when treated as a destination.
The perfectly coherent landscape remains valuable as a reference. It clarifies what consistency, integration and global alignment can achieve under stable assumptions. But once change is treated as a certainty rather than an exception, those same qualities stop being the primary optimisation target.
What matters then is not how elegant a system looks on paper, but how it behaves under pressure.
A better IT landscape is not the one that holds together most tightly. It is the one that can change without forcing everything else to change with it.
That shifts the ambition of enterprise architecture. Instead of maximising global consistency, the goal becomes to design systems that are:
easier to change locally, without requiring system-wide coordination
easier to reason about, even when no single person understands the whole
easier to explain, without relying on tribal knowledge or heroic individuals
easier to abandon in parts, when assumptions no longer hold
These are not signs of architectural weakness. They are indicators of resilience.
Designing for local change means accepting boundaries, buffers and occasionally duplication.
Designing for comprehension means limiting connectivity even when tighter integration would be technically possible.
Designing for abandonment means recognising that not every component deserves to be permanent.
Such landscapes look less impressive in diagrams.They tolerate inconsistency. They accept latency. They prioritise containment over optimisation. What they offer in return is something the perfect landscape cannot:the ability to evolve without becoming unmanageable.
The ideal IT landscape, imagined without constraints, shows us what coherence can achieve.But real value lies in knowing where to stop, what to isolate, and what to let go.
Enterprise architecture, in that sense, is not about designing the most integrated system possible. It is about designing systems that can change, and be abandoned, without breaking the organisation that depends on them.
Diagnosis lens: are we designing for a static world?
These questions are not meant to be answered perfectly. They are meant to surface hidden assumptions.
Where does our architecture assume stability that does not exist? Look for designs that only work if business structures, regulations or data definitions remain unchanged. If a small external change forces broad coordination, the system is optimised for stasis.
Which integrations would we hesitate to touch today?Every integration that feels too risky to change already limits adaptability. Not because it is wrong, but because its impact is unclear or unbounded.
Where have we optimised global consistency at the cost of local change? Shared models and real-time synchronisation are efficient under static assumptions. Under constant change, they convert local adjustments into system-wide effort.
Which inconsistencies do we tolerate implicitly rather than manage explicitly Inconsistency itself is not the problem. Unacknowledged inconsistency is. Hidden divergence creates surprises. Visible divergence can be governed.
What decisions have we deferred by encoding them into architecture? Unclear ownership, unresolved trade-offs and political compromises often reappear as technical complexity. Architecture then carries decisions that were never consciously made.
Comments