Experiences from technical deliveries in critical industry

Digitalisation in energy and process industry rarely starts with a lack of ambition. On the contrary. Most organisations we work with have already invested significantly in new platforms, modern tools and more advanced use of data. Yet many find that the impact fails to materialise, or that solutions end up sitting alongside actual operations rather than becoming part of them.

The interesting thing is that this rarely comes down to the technology itself. The problems appear when solutions meet a system landscape built for stability, not continuous change. When new digital initiatives are pushed into this reality without accounting for how operations, domain knowledge and architecture actually connect, the friction becomes apparent quickly.

For technical leaders, this is a familiar picture. And in critical industry, the issues that derail a delivery are almost always the ones that could have been caught earlier — if someone had read the terrain properly before moving into it.

Architecture decisions you cannot avoid

In critical industry, early architecture choices determine whether a digital solution scales into operations or stalls after the pilot. Systems that seem bounded at the start rarely stay that way for long.

Many digital initiatives start as relatively contained solutions. They are meant to solve a specific need, demonstrate value and ideally go live quickly. Which is a good thing. The challenge is that these solutions rarely remain contained for long.

Once in use, new needs emerge. Data must be shared, functionality extended, and the solution must relate to more systems than originally planned. That is when early architecture choices become very visible. Temporary integrations become permanent. Data models that worked locally create inconsistency when scaled. And technical debt accumulates faster than anticipated.

In critical industry, this is especially demanding because systems can rarely be isolated from operations. Changes have consequences, and rollback is not always an option. That is why the most robust solutions we have seen are those built from the start with a clear relationship to the whole. Not necessarily large and heavy, but deliberate. With clear interfaces, explicit data ownership and an understanding of how the solution will live on after the first delivery.

Data models and integrations are where things break

Poor data modelling and unclear integration contracts cause more failed digitalisation projects in critical industry than any technology limitation. When data representing physical, time-dependent states is flattened into generic tables, meaning gets lost.

We often see good initiatives hit the wall at the intersection of data modelling and integration. Not because the solutions lack structure, but because they are modelled for one context and then expected to work across many. In critical industry, data typically represents something physical and time-dependent: a state, a configuration, a decision made at a specific point in time. When this is flattened into generic tables or APIs without clear semantics, ambiguity about what the data actually means emerges quickly.

Many solutions start with a pragmatic choice: expose what you have, as it is. That works perfectly well in the beginning. The problem appears when multiple systems start consuming the same data for different purposes. Then it becomes clear that you are not just integrating systems, but also assumptions. Small differences in understanding of concepts, status or ownership have consequences that only show up when something fails in operations.

The most robust solutions we have seen are those where a position is taken early on what the data actually represents, and where integrations are built around clear contracts rather than internal structures. Not necessarily heavy domain modelling, but an awareness of which data is truth-bearing, who owns it, and how change is handled over time.

When standards become part of the workflow

Industry standards in energy and process sectors work best when digital tools are designed around how domain experts actually use them, not around the documentation itself. This shift in perspective changes adoption entirely.

Standards play a central role in energy and process industry. At the same time, many find them demanding to work with in practice. Not because the standards are wrong, but because the tools around them are often built with the documentation as the starting point, not the use situation.

When digital solutions take the actual working practices of domain experts as their starting point – how models are created, changed and used over time – something different happens. The standard becomes a framework that supports work rather than a barrier to be circumvented.

We have seen that solutions developed this way gain traction quickly. Not because they simplify away complexity, but because they make it manageable. This also gives far better conditions for further development, because you build on existing practice rather than trying to replace it.

The transition from pilot to production

Most technical initiatives work well in pilot. It is often only when they need to scale into ordinary operations that the real challenges become visible – not necessarily technical, but organisational and structural.

Project models with fixed scope and clear end points are a poor fit when both needs and understanding evolve along the way. At the same time, we often see responsibility fragmented across multiple suppliers, making it difficult to take holistic decisions when something does not work as expected.

For a CTO or technical leader, this typically means sitting with ultimate responsibility but limited ability to influence the details that actually determine the outcome. The deliveries that succeed best are therefore often those built by stable teams over time. Teams that understand the domain, the system landscape and the consequences of the architecture choices being made, and that can adjust course without having to start over.

Agility with control

Agile development in critical industry requires a different kind of discipline. Continuous change without clear guardrails creates uncertainty, not progress. The technical leaders who succeed combine agile methods with traceability, quality requirements and controlled deployment.

That does not mean going back to heavy processes, but that agility must be combined with traceability, clear quality requirements and controlled rollout. The technical leaders who succeed best use agile methods as a tool for learning and improvement, not as an excuse for unresolved decisions.

In the delivery systems we build, safety is not an audit layer pasted on at the end. It is three layers built into the engine: the standard controls that apply on every project (code review, dependency scanning, vulnerability detection, privacy audit, spec validation), the customer-specific layer (industry standards, internal security requirements, regulatory obligations, customer approval flow), and a human approval gate on every critical decision. A skill that works 85–90% of the time with a human in the loop can fail 100% of the time in an automated pipeline without one. That asymmetry is permanent and it is why human approval is not a bottleneck — it is the architecture.

A different view of the partner role

Organisations in critical industry are shifting from buying individual deliveries to building long-term technology partnerships. Not to give up control, but to get more of it — through fewer interfaces, greater transparency and partners who take responsibility for the whole.

The partnership model that works in critical industry has two sides, not one. A bridge has two sides: both must stand for it to have function. The customer is not a guest looking into the supplier's system. The customer stands on their side of the bridge, the partner stands on theirs, and the working surface — backlog, decisions, cost, progress, security posture — is owned jointly. Fewer interfaces, greater transparency, and partners who take responsibility for the whole give better conditions for making the right technical choices over time. Especially when solutions need to live long, be continuously developed, and integrated ever deeper into core operations.

Precision beats speed

Technology will continue to develop rapidly. There will always be new platforms, new standards and new possibilities. For technical leaders in critical industry, the challenge is rarely just to keep up, but to adopt these in a way that actually strengthens operations.

Those who succeed best are rarely those who move fastest. They are those who move precisely. Who make architecture choices that withstand change, and who build solutions close to both operations and domain expertise. Humans lead. Agents execute. Skills compound. And nothing ships without passing through the controls the domain actually requires.

When digitalisation is treated as an integrated part of the business, and not as a separate initiative, it stops being a risk project. It becomes a natural part of how the organisation continues to develop.