The CTO pain: Reconstructing a moving business through technology
Why versioning, fragile pipelines and the gap between business and engineering make success so difficult. If you are the CTO of a growing energy developer, there is a good chance your team has gradually inherited a very difficult responsibility: reconstructing the business through technology.
Luis Cabello5 min read
Why versioning, fragile pipelines and the gap between business and engineering make success so difficult.
If you are the CTO of a growing energy developer, there is a good chance your team has gradually inherited a very difficult responsibility:
reconstructing the business through technology.
Development has one system.
Land has another.
Finance has its own stack.
GIS contains part of the truth.
Project Managers still rely heavily on Excel.
ERP knows transactions.
Management wants one reliable portfolio view.
And somehow Technology is expected to make all of it behave like one coherent operating model.
At first, this looks like an integration problem.
It is not.
The real problem is that you are trying to reconstruct a business that never stops moving.
Versioning is the hidden nightmare
One of the most valuable questions management can ask sounds deceptively simple:
How far has this project moved from the approved baseline?
Take RtB.
Today it is 30 September.
But perhaps the approved baseline was 30 June.
What was the project capacity at that time?
What was the health status?
What COD was assumed?
Which permits were considered complete?
Which dependencies were still open?
Answering that properly requires versioning.
And versioning is hard because project information contains two very different kinds of data.
Some information is relatively permanent:
Project code. Project name. Location.
Other information continuously evolves:
Capacity. Milestones. Status. Forecasts.
A robust architecture needs to preserve the permanent identity of the project while being able to reconstruct what its moving reality looked like at any relevant point in time.
Simply overwriting the current value destroys history.
Duplicating the entire project every time something changes creates another problem.
So Technology starts building snapshots, historical tables, transformations and increasingly sophisticated logic just to answer:
What changed?
This is why versioning becomes something close to a holy grail in portfolio systems.
It looks simple from the outside.
Technically, it is anything but.
Then somebody adds one new permit
Eventually the architecture works.
The pipelines run.
The reports reconcile.
The organization starts trusting the output.
And then the business enters another country.
Someone says:
“We need to add this permit.”
From the business perspective, that is a completely reasonable request.
But downstream, one new data point can affect the data model, integrations, transformations, APIs and reports.
The same happens when BESS is introduced.
Or a country follows a different permitting sequence.
Or Construction wants another milestone.
Or Finance needs a new project attribute.
The problem is not that the business keeps changing.
The business is supposed to change.
The problem is an architecture where every legitimate business evolution becomes another development cycle.
That is where apparently robust systems become fragile.
They were robust for yesterday’s operating model.
Then the business moved.
The hardest profile to hire sits between two worlds
There is another challenge that technology alone cannot solve.
The people building the system need to understand what they are building.
At one extreme, you can find exceptional technical profiles.
They understand cloud architecture, APIs, data models and engineering patterns beautifully.
But ask why RtB matters, how a permit affects a milestone, or why the same SPV may contain two operational projects, and the business context may simply not be there.
At the other extreme are people who understand the business deeply but cannot translate that understanding into a robust technical product.
The person who can genuinely bridge both worlds is rare.
And expensive.
Yet companies often use that scarce talent to repeatedly rebuild fairly standard pieces of the energy-development operating model.
Another permitting workflow.
Another milestone structure.
Another portfolio model.
Another reporting layer.
That is a huge opportunity cost for Technology.
Then comes another “solution”
CTOs also operate in an environment full of extremely well-packaged technology.
Snowflake.
Kafka.
Databricks.
Modern transformation frameworks.
Lakehouses.
Analytics platforms.
AI platforms.
Many of them are excellent technologies.
The mistake is expecting infrastructure to solve the operating-model problem itself.
A data platform can store and process enormous amounts of information.
A streaming platform can move it extremely efficiently.
An analytics layer can visualize it beautifully.
But none of those technologies inherently knows:
Which permit is a prerequisite for RtB?
Which milestone belongs to the approved baseline?
Which project dependency threatens the financing assumption?
That meaning still has to be designed somewhere.
And if it does not exist close to the business, Technology ends up reconstructing it downstream.
Again.
And again.
And again.
The architecture becomes increasingly sophisticated.
But a sophisticated reconstruction is still a reconstruction.
Your data platform should not have to reconstruct your business
This is where I believe the architecture can change.
ERP should remain ERP.
Treasury should remain Treasury.
Power BI should remain an excellent consumption layer.
Enterprise data platforms should continue doing what they do well.
The missing piece is the governed operational layer between execution and those systems.
A place where projects, versions, milestones, permits, dependencies, risks, ownership and commitments already exist with business meaning attached.
Then downstream systems can consume project reality instead of continuously inferring it.
That is a much simpler proposition.
And it also changes what Technology can spend its time on.
AI makes this problem impossible to ignore
Today, almost every CTO is being asked some version of:
“What are we doing with AI?”
The temptation is to connect AI to everything.
Documents.
Databases.
Data lakes.
Reports.
But AI connected to fragmented context does not magically create a governed organization.
It may simply reconstruct the fragmentation faster.
The interesting AI capabilities appear when the context already understands the business.
Which milestone is approved.
Which permit affects it.
Which project version is current.
Who owns the mitigation.
What financial assumption depends on that commitment.
Then you can ask:
Which RtB commitments have moved more than 90 days from baseline, why, and which financial assumptions may now be stale?
That is not simply document retrieval.
That is reasoning over the operating model.
The CTO opportunity is not less technology
It is better allocation of technology.
For years, building custom operating infrastructure inside energy companies was often rational.
There were few alternatives capable of representing the complexity of project development properly.
But that is changing.
A configurable operating platform can now absorb much of the recurring complexity around projects, countries, technologies, versions and governance.
And that means your strongest technical people can spend less time reconstructing the business.
And more time creating differentiation.
Architecture.
Security.
Integration.
Automation.
AI.
Things that genuinely create competitive advantage.
The principle is simple:
Buy the operating model. Build the differentiation.
Because your technology team should not have to rebuild the company before it can improve it.
Navorda for CTOs & Technology Leaders — the role page behind this article
Navorda Connect — governed context for Power BI, data platforms and enterprise systems
Navorda MCP Connector — governed, read-only context for enterprise AI
What’s in Navorda for me? — one operating model, five very different reasons to care
Enter it once. Use it yourself. Trust what gets reported. — the Project Manager chapter
