Executive summary
Enterprise software has always had the same problem. The person who understands the work is rarely the person who builds the system. A domain expert explains what they need. A software team builds it. Something gets lost in translation. A project takes months. The system goes live. It already needs changing.
That gap is closing.
Cloud-native, low-code platforms have changed what domain experts can do themselves. In oil and gas, that means a hydrocarbon accountant can now build the system that runs production allocation. A production engineer can configure the reporting logic for a complex JV. They do not need to write a specification. They build directly, using skills they already have.
The same shift is happening wherever operations are complex, data-heavy, and regulated. The people who understand the domain best are becoming the people who build and own the tools that run it.
This is not a small upgrade on the old model. It is a different model.
This paper looks at what domain experts can build when they have the right platform. It uses oil and gas as its primary example, because it is one of the most demanding environments in the world for data management. And it looks at what separates a platform that genuinely serves domain experts from one that simply says it does.
The expert in the room
Every complex operation has one. The person who has spent years learning how a particular part of the business works. They know the contracts, the regulations, the edge cases, and the history. They know why the numbers look the way they do, and they are usually the first person anyone calls when something does not add up.
In oil and gas, that person might be a hydrocarbon accountant. A production engineer. A data analyst who has spent a decade on the same asset. They are not software developers. But they understand the problem better than any software developer ever could.
For most of the history of enterprise software, that person has been a passenger. They explain what they need. Someone else builds it. The result is a system that approximates their knowledge rather than reflects it. When something changes, they go back to the queue.
This is not a small inefficiency. In a regulated industry where data underpins commercial agreements, royalty payments, and regulatory returns, a system that does not quite reflect how operations work is a liability. Errors compound. Workarounds multiply. The gap between how the system works and how the business works grows quietly over time.
The problem is not the people. The problem is the tools.
Most enterprise software whilst built for domain experts to use, wasn’t built for them to manage. It was built for IT departments to deploy and manage. The assumption was that technical complexity required technical ownership. Domain experts were users of systems, not builders of them.
That assumption made sense when building software required specialist skills. It makes less sense now.
Low-code platforms have separated the ability to build from the ability to code. Domain experts can now design workflows, configure calculation logic, and build data models using tools that feel closer to Excel than to a programming language. The technical infrastructure sits underneath, managed by the platform. The expert stays on top, shaping the system to fit the work.
In oil and gas, where no two operations are identical, and the rules that govern them change constantly, that shift matters enormously. The person who understands the problem can now be the person who owns the solution.
What domain experts can build
The O&G data challenge
Oil and gas is a useful test case for any data platform. The operations are large and complex. The data is interconnected. The rules that govern it change. And the consequences of getting it wrong are significant.
A single upstream asset might involve production data from dozens of wells, allocation logic across multiple joint venture partners, regulatory reporting to several different bodies, and commercial calculations tied to long-term contracts. Each of those elements has its own rules. Many of them interact. And all of them need to be right.
Traditional software handles this by encoding the rules into the system at build time. If the rules change, the system needs to change too. That means a vendor conversation, a scoping exercise, a project, and a wait. For an industry where regulations shift, assets are acquired and divested, and JV agreements are restructured regularly, that pace of change is a problem.
A configurable platform handles it differently. The rules live in the configuration, not in the code. When a regulation changes, the domain expert updates the logic. When a new asset comes online, they extend the model. When a JV partner requires a different allocation methodology, they build it. The system reflects the operation because the person who understands the operation built it.
Building in a language you already know
The practical question is always the same: if domain experts are going to build their own systems, what do they build with?
The answer, in most O&G operations, is already sitting on their desktop. Excel is the most widely used calculation tool in the world. Hydrocarbon accountants think in Excel. Production engineers model in Excel. Data analysts validate in Excel. It is not a workaround. It is the language the industry already speaks.
A platform built for domain experts uses that language as its foundation. Calculation logic is written in Excel-based formulas. Data models are structured around the way the business actually works. Workflows follow operational processes rather than software conventions.
This matters for two reasons. First, the barrier to building is low. A domain expert with strong Excel skills can learn to configure on a platform like this in days, not months. Second, the output is transparent. The logic is visible and inspectable. When a regulator or JV partner asks how a number was calculated, the answer is in the system, not buried in a vendor’s codebase.
What gets built
The range of what domain experts can build on a configurable cloud platform is broader than most people expect.
Production allocation systems that reflect the exact contractual and regulatory rules of a specific asset. Hydrocarbon accounting workflows that cover the full value chain from wellhead to invoice. Emissions tracking tools built to the specific reporting requirements of a particular regulator. Cargo scheduling and nomination systems for LNG operations. Pipeline management and tariff calculation tools. Reporting portals that give JV partners and shippers direct access to their own data.
None of these are generic applications. Each one is built to reflect how a specific operation actually works. That specificity is the point. A system that reflects reality is more accurate, more auditable, and more useful than one that approximates it.
What a platform built for domain experts looks like
The difference between configurable and customisable
Most enterprise software vendors claim to be adaptable. But there is a meaningful difference between a system that can be customised and one that is genuinely configurable.
A customised system is built around your requirements at a point in time. The vendor scopes the work, builds to the spec, and delivers something that fits your operation today. When the operation changes, you go back to the vendor and start again. The system is yours in name. The logic belongs to someone else.
A configurable platform works differently. The vendor provides the infrastructure, the calculation engine, the security, and the workflow tools. The domain expert builds the application on top, using those tools to define exactly how their operation works. The logic is theirs to create, inspect, and change.
In practice, this means a hydrocarbon accountant can build allocation logic that reflects the exact rules of a specific JV agreement, not a generic approximation of it. A production engineer can model a new asset configuration without waiting for a software update. When a regulator changes a reporting requirement, the team that understands the requirement changes the system.
That distinction sounds technical. The consequences are not. It is the difference between a system that serves the business and a system that the business works around.
Transparency and auditability
In a regulated industry, a system is only as good as the trust placed in it. And trust requires transparency.
Legacy platforms are often described as black boxes. The calculation logic sits inside the vendor’s code. You can see the output. You cannot always see how it was produced. When a regulator asks how a royalty figure was calculated, or a JV partner questions an allocation, the answer should be immediately available. In a black box system, it often is not.
A platform built on Excel-based logic changes that. Every calculation is open and inspectable. Audit trails show every change, who made it, and when. The logic is written in a language that regulators, JV partners, and internal teams already understand.
When you can show exactly how a number was produced, disputes are shorter and confidence is higher.
The platform should disappear
There is a useful test for any platform that claims to serve domain experts. Does the expert spend their time thinking about the platform, or thinking about the problem?
In a well-designed system, the platform disappears. The expert is focused on the data, the logic, the operation. The infrastructure sits underneath, handling security, uptime, updates, and scale. It does not surface unless something goes wrong, and even then, the tools to understand and fix the problem are accessible to the people who need them.
For O&G domain experts, that mental model is built on Excel. Calculations work like formulas. Data flows like a spreadsheet. The logic is readable. When a new person joins the team, they can understand how the system works without a six-week training course.
That is what makes a platform sustainable over time. Not just the initial build, but the ability of the team to own, understand, and evolve it as the business changes.
What this looks like in practice
Reporting that runs itself
Ancala Midstream manages critical North Sea infrastructure, including the Scottish Area Gas Evacuation pipeline and terminal. Before moving to a configurable cloud platform, the team was generating over 1,000 reports by hand each day, sending them to the companies using their pipelines to buy and sell gas.
After building on EnergySys, those customers log into their own portal and see their data directly. The reports run themselves. The team that previously spent its time producing outputs now spends its time on the work those outputs are supposed to support.
As one team member put it, that was only possible because the platform is cloud-based. It was a huge change for them. And when emissions rules changed, the same team built an emissions tracking tool on the same platform. No new vendor. No new project. They extended what they already owned.
Changing a system when the operation changes
Santos is one of Australia’s largest oil and gas producers. Like most operators, they run operations that change over time. Assets are reconfigured. Flow networks are reversed. Reporting requirements shift.
Under a legacy system, each of those changes meant a conversation with the vendor, a scoping exercise, and a bill. Under a configurable platform, the domain expert makes the change. Santos described it plainly: you can see how the system works, see where things go wrong, and update it yourself. What would previously have been a large vendor bill is now a configuration change.
That is not just a cost saving. It is a change in who controls the system. The operation no longer has to wait for the vendor to catch up.
Reuse at scale
When BPX Energy acquired a large portfolio of US onshore assets, they faced a tight integration timeline. They needed to retire the inherited legacy systems and consolidate operations fast, with no appetite for a large consultancy project.
BPX was already using EnergySys to manage its existing assets. So they did something straightforward. They spun up a new instance using the same configuration they already had, made a few targeted adjustments to accommodate the new data model, and rolled it out. No third-party integrators. A small internal team. Live in weeks.
That is what reusable, domain-expert-built configuration looks like at scale. The knowledge was already in the system. They applied it to a new problem.
Moving fast when it matters most
TAQA acquired North Sea assets including the Brent Pipeline system and found that the inherited data system could not handle the added complexity. They had a short window to replace it or extend a licence on a system that was already struggling.
They chose to replace it. EnergySys was live within the critical window. TAQA’s own team handled allocation logic and reporting from day one. As one team member said: what they did, and how fast they did it, would not have been possible with any other tool.
That kind of speed is only possible when the people building the system understand the operation. A vendor building to a spec cannot move at that pace. A domain expert building on a configurable platform can.
The pattern
Across these cases, the same thing is true. The domain expert understands the problem. They have the tools to solve it. And the results are faster, more accurate, and more sustainable than anything a vendor could have built on their behalf.
That is the point of a platform built for domain experts. Not to replace the expert. To give them the power to build.
Find out what your team could build
EnergySys is the configurable cloud platform for domain experts. It gives the people who understand your operations the tools to build, own, and adapt the systems your business runs on.
See what it can do for your team, explore the EnergySys platform, or get in touch at sales@energysys.com.
