Standardisation Without Rigidity: A Practical Approach to Infrastructure Transformation

How clear principles, governance and phased change can reduce complexity without ignoring operational reality

Standardisation is one of those ideas that is difficult to argue against.

Most technology leaders want fewer unnecessary variations, clearer support models and infrastructure that can be changed without having to rediscover how everything works. Standards can make services easier to secure, automate and operate. They can also reduce dependence on the knowledge held by a small number of people. The difficulty usually begins when standardisation moves from being a useful principle to becoming the objective in its own right.

Real infrastructure environments are rarely consistent. They have been shaped by years of projects, urgent business requirements, acquisitions, technology refreshes and decisions that made sense at a particular point in time. Some differences are accidental. Others exist for valid technical or operational reasons.

A successful transformation needs to understand the difference. My view is that standardisation should be an outcome of maturity and governance, not the starting objective.

The journey from a complex environment to a standardised one is rarely a direct migration. In practice, organisations move through a series of maturity stages before standardisation begins to deliver sustainable operational benefits.

The framework below shows a common progression. In practice the stages overlap, and sequencing should follow risk rather than a fixed order.

The progression moves from visibility and ownership, through governance and controlled exceptions, to standardisation, with better operational outcomes as the result rather than the starting point. Standardisation sits near the end because it only holds once the organisation knows what it has, who owns it and which differences are justified.

How variation accumulates over time

Infrastructure does not normally become inconsistent because someone deliberately designed it that way.

A project may introduce a platform to meet an urgent deadline. Another team may select a different approach because the existing standard cannot support a particular requirement. A temporary exception remains in place because replacing it would interrupt a critical service.

Over time, these decisions begin to overlap and accumulate.

Documentation may describe the intended environment (the ideal state) rather than the one actually operating. Similar services may have different monitoring arrangements, support processes or lifecycle dates. Two configurations that appear identical at first glance may contain small differences introduced during earlier incidents or migrations.

I once saw two sites built from the same design and documented identically. During a routine change, one behaved differently. The cause was a small workaround added during an incident years earlier, never formally recorded and known only to one engineer, who had since moved on. The change was delayed, and the real cost was the time spent rediscovering why the workaround existed.

None of this automatically means that previous decisions were wrong. Context changes, and technology decisions are usually made within the constraints that exist at the time. The problem is that the original context is easily lost. When nobody can explain why an exception exists, who owns it or what would happen if it were removed, variation becomes difficult to distinguish from risk.

The attraction of a single standard

The desire for standardisation is understandable. A common architecture can simplify engineering, procurement and support. Repeatable configurations are easier to automate. Security controls can be applied more consistently, and teams have fewer patterns to learn. Suppliers can also be managed against clearer expectations.

There is real value in all of this.

But adopting one design everywhere does not necessarily create a standard operating environment. If the target model does not account for application dependencies, service criticality or the organisation’s ability to support it, teams may simply create new exceptions around the new standard.

The diagrams become consistent while the operational reality remains fragmented.

This is particularly important in large or established environments. A design that works well for a new service may not be appropriate for a platform carrying years of technical and business dependencies. Forcing both through the same migration path can introduce risk without delivering a proportionate benefit.

Standardisation should reduce unnecessary complexity. It should not remove judgement.

Start with principles rather than products

A practical transformation should begin by defining what the organisation wants its infrastructure to achieve. That sounds obvious, but programmes can move quickly into technology selection, detailed designs and migration schedules before agreeing what “standard” actually means.

A useful set of principles might include:

–    services should have clear technical and operational ownership, and platforms should have understood lifecycle and support arrangements;
–    security controls should be proportionate to the service and its risk;
–    monitoring and resilience should reflect business requirements, with meaningful visibility across the service path;
–    repeatable changes should be delivered consistently and, where appropriate, automated; and
–    exceptions should be visible, justified and reviewed.

These principles do not prescribe a particular platform. They provide a basis for evaluating different designs and making trade-offs openly.

They also help when the preferred technical pattern cannot be applied. A team may need to retain an older platform, for example, but it can still improve its monitoring, ownership, documentation and recovery arrangements. Progress does not always require immediate replacement.

Not every exception is a failure

The word “exception” often carries a negative meaning in transformation programmes. It can sound like something that must be eliminated before the work can be considered complete.

Some exceptions should certainly be removed. They may result from outdated assumptions, configuration drift or decisions that are no longer relevant. Others may be justified.

An application might rely on a protocol that cannot yet be changed. A regulated service may require a different control model. A location may have connectivity or operational constraints that make the common design unsuitable. In another case, the cost and risk of migration may simply outweigh the benefit at that point in the service lifecycle.

The important question is not whether exceptions exist. It is whether they are understood and documented clearly. A controlled exception should have a reason, an owner and a clear description of the associated risk. Its support arrangements should be known, and there should be some point at which the decision is reviewed.

Without that discipline, exceptions have a habit of becoming permanent by default. They may then be discovered during an incident, an audit or a major change, which is usually the least convenient time to understand them.

Standardise the operating model as well

Infrastructure standardisation is often discussed through technical patterns: common hardware, approved architectures, configuration templates and preferred services. Those elements matter, but the operating model deserves the same attention.

Two platforms built to the same technical design can produce very different service outcomes if they are monitored, supported or governed differently. One may have clear escalation routes and tested recovery procedures. The other may depend on informal knowledge and best-effort support.

Technical consistency alone will not close that gap. A mature standard should therefore consider how a service enters operation, how changes are controlled, how incidents are escalated and how lifecycle decisions are made. It should define the evidence required before a platform is accepted into support.

This is where infrastructure, security, service management and application teams need to work together. None of those functions has a complete view on its own.

In my experience, some of the most useful transformation conversations happen when the discussion moves away from “Is the design compliant?” and towards “Can we operate this reliably when something unexpected happens?” The answers are not always the same.

Transformation needs a sequence

Trying to remove every inconsistency at once is rarely practical. Organisations have limited engineering capacity, change windows and investment. Application teams also have their own priorities. A transformation plan that ignores these constraints may look ambitious but become difficult to sustain.

Sequencing should be based on more than technical age. A platform with an older design may be stable, well understood and approaching retirement. Another may use newer technology but suffer from poor visibility, unclear ownership and repeated operational incidents. Refreshing the oldest technology first would not necessarily address the greater risk.

Prioritisation might consider:

How much risk does this carry?

–    service criticality;
–    security exposure;
–    frequency and impact of incidents; and
–    level of configuration variation.

How ready is it to change?

–    dependency readiness;
–    availability of skills; and
–    lifecycle and support status.

Is the change worth the effort?

–    operational effort; and
–    the value that change would deliver.

This allows the programme to focus on the areas where standardisation will make a meaningful difference. It also creates space for phased improvement. An organisation may strengthen monitoring and ownership first, standardise configuration later and replace the underlying platform when the service is ready.

That may be less visually impressive than a single large migration, but it can produce a more durable result.

Measure outcomes, not conformity

A transformation can report that platforms have been migrated, templates deployed and exceptions reduced. Those measures are useful, but they do not tell the whole story. The real test is whether the environment has become easier to manage.

Are routine changes more consistent? Can teams identify service dependencies more quickly? Has repeat incident volume reduced? Are recovery arrangements understood? Can new engineers support the environment without relying heavily on individual knowledge?

It is also worth looking at the exceptions that remain. Are they actively owned, or have they simply disappeared from the programme dashboard? Not every benefit can be reduced to one metric. A combination of operational, risk and service measures is usually more informative than a percentage-compliance target on its own.

The objective is not to demonstrate that everything looks the same. It is to create an environment that behaves more predictably and can be supported with greater confidence.

Questions worth asking

When reviewing a standardisation or infrastructure transformation programme, I find the following questions useful:

–    What problem is the standard intended to solve?
–    Which variations create genuine operational or security risk, and which have a valid business or technical justification?
–    Who owns the target standard after the programme finishes?
–    Who can approve an exception, on what basis, and when will it be reviewed?
–    Do teams have the skills, capacity and support arrangements, including monitoring and recovery, to operate the target model?
–    How will we know that the service has actually improved?

If you only ask three, ask: what problem does the standard solve, who owns it afterwards, and how will we know it improved? These questions do not remove the need for technical standards. They help ensure that those standards remain connected to the outcomes they are meant to support.

A more sustainable definition of standardisation

Successful standardisation is not about making every part of the environment identical. It is about reducing variation that has no continuing purpose, making necessary differences visible and ensuring that both can be operated responsibly.

That requires architecture, governance and operational judgement. It also requires patience. Established environments cannot always move at the speed suggested by a transformation diagram.

Clear principles provide direction. Standards make repeatable delivery possible. Exceptions allow the organisation to respond to genuine constraints. The balance between them is what makes transformation workable. For me, the practical test is straightforward: has the change made the environment easier to understand, safer to modify and more sustainable for the people who will operate it?

If the answer is yes, standardisation is delivering value.

If everything is technically compliant but teams are still working around the model, there may be more work to do. How does your organisation distinguish between a justified exception and unmanaged variation?