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.

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.

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.

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.

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.