— Current
Governing the capital portfolio of a national aviation system
MATARAT Holding stewards Saudi Arabia's airports, and its Project & Technical Affairs department (P&TA) sets and governs the National Capital Projects Portfolio — every capital project across five operating companies, from first idea to board approval.
I am employed by Egis, which serves as the Project Management Office for P&TA — the Airport PMO that runs the department's project governance day to day. So everything below was designed from inside that governance rather than proposed to it from outside: first the CAPEX platform that took the 2026 budget cycle off email, then CIMS, the system that governs the entire project life cycle of which CAPEX is one chapter.
Strategy & P&TA
Five operating companies submit capital proposals upward. P&TA reviews, endorses, and consolidates them into one annual investment plan aligned to the National Aviation Strategy — 27 airports in scope.
MATARAT Intelligent CAPEX Budget Cycle Platform
The 2026 CAPEX cycle had to run before any enterprise system existed. So I built one on the ground already under our feet — the Microsoft 365 estate MATARAT already owned. No new platform, no new vendor, no additional licence cost.
Auto-detects what changed between business-case versions and judges whether reviewer comments were actually addressed — fully, partially, or not at all. Reviewers read only the delta, not the whole document again.
Generates signature-ready PDF business cases from validated data. Templates auto-populate — formatting inconsistency and manual drafting stop existing as a category of work.
Continuous visibility of submission progress, iterative reviews, and pending tasks across every OpCo and department — which removed the follow-up email as an instrument of project management.
Business-case preparation and technical review went from days to minutes. Real-time consultation replaced email delay. The measurable win was cost and time; the structural win was that the portfolio finally had one governed record.
Submitted to Egis' internal innovation competition, the platform advanced through the first and second rounds and was presented in the final. It didn't take a podium place — but the work it proved became the mandate for something much larger.
ROLE: SOLUTION ARCHITECT & DEVELOPER
CIMS — Capital Investment Management System
The CAPEX platform governed one chapter of the story: the annual budget cycle. CIMS governs the whole book — the PMO's system of record across the full airport project life cycle, from first idea to board report. Thirteen modules, built on Dataverse behind an Entra ID sign-in and a single-licence secured gateway, with server-side data scoping per company and a full audit trail. Delivered as a 71-item, Jira-tracked program with a live client-facing dashboard — by a two-developer core team working to my architecture and direction.
A team that small only works if the thinking is done before the building starts. The figures below trace where that thinking happened: the requirements arrived as sentences from people who don't write software, and my job was to turn each one into a decision a system can enforce.
The interim platform was never the destination. It proved — on live national data, under a real board deadline — that governed automation works here. That proof is what made the case for the full life-cycle system.
Nobody at MATARAT asked for row-level security or a service principal. They described a problem in their own words, in a meeting, about their own job. The work I do is the sentence in the middle — turning that into a decision a system can enforce. Every module in CIMS started life on the left-hand side of this diagram.
This is the part a vendor cannot buy its way past. The architecture on the right only looks obvious after someone has sat in the meetings on the left — which is why the design workshops ran per real MATARAT process: portfolio & change control, CAPEX in-cycle and off-cycle, Stage Gate 2, Stage Gate 3.
I set the architecture, wrote the governance design, and directed the build. Two developers executed against it. The reason that was enough is upstream of the code: the ambiguity had already been removed before anyone opened an editor.
Progress is reported to the client on a live, Jira-connected dashboard — no login, open link. The delivery of a governance system is itself governed and visible, which is the only honest way to build one.
The hardest constraint wasn't technical, it was commercial: a per-user database licence across five operating companies was never going to be affordable. The obvious answers all traded security for cost. This one doesn't — it took thirty engineered steps to make it both work and stay safe.
A per-user database licence for every user in every operating company — a recurring bill that would have made the whole system unaffordable, and the reason most builds of this shape never start.
- Every request checked against the real Entra sign-in — signature, audience, expiry.
- Each person sees only their own OpCo's data, scoped on the server, never in the browser.
- Every create and edit stamped with who did it — a defensible record, not a log.
And nobody had to wait for it. Interim bridges let the operating companies start submitting change requests while the secured path was still being built, then those bridges were cleanly removed at go-live. Nothing built was thrown away — the record simply carried forward.
Dataverse as the record layer, Entra ID for identity, one secured gateway licence rather than per-user seats — built entirely on the estate MATARAT already owns.
Server-side data scoping per operating company, full audit trail, and separation of duties — five companies in one system without seeing each other's portfolios.
A 71-item Jira-tracked program with a live client-facing progress dashboard — the delivery of the governance system is itself governed and visible.
Turning a national satellite into operational decisions
Team Leader, promoted from Geospatial Solutions Architect — delivering a work package under THEOS-2, the programme in which Airbus built Thailand's second Earth-observation satellite for GISTDA. A satellite does not deliver decisions. It delivers layers. My package was the machinery in between: turning what the spacecraft sees into what a minister can act on.
The study area was Thailand's Eastern Economic Corridor and the question was water — twenty years of forecast rainfall on one side, thirty interconnected reservoirs and a growing industrial region's demand on the other. The package was named for what it had to produce, not for what it was made of.
Four disciplines had to meet in one chain — and the joins were the hard part. Remote sensing gives you layers, hydrology gives you a model, but nothing in either tells you what a reservoir operator already knows, or what a governor is allowed to decide. The figures below follow that chain end to end.
Every pass adds observations, and each one is a separate surface with its own units, cadence and error. None of them is a decision. The work is knowing which layers combine into which question — and being able to defend the combination to a hydrologist.
Rainfall alone tells you how much water arrived. Only rainfall with terrain, geology and temperature tells you how much of it a reservoir will still be holding next month — which is the number an operator can act on.
The forecast was only half the answer. The other half sat on the ground, with Thailand's irrigation authority, so I went and collected it. Thirty reservoirs across the Eastern Economic Corridor, each with real records — and each kept in its own way, on its own cycle, in its own file. Every reservoir was documented. Nowhere was it written down how they behaved as one system.
This is the piece of the package I'm proudest of, and the least visible. Nobody handed me the network — it came out of site visits, interviews and a lot of arguing with records that disagreed. Turning thirty separate custodial habits into one defensible model is what let everything downstream exist.
A model that only a modeller can read has not finished the job. The package ends in an interactive executive dashboard holding three scenarios side by side — so the question stops being "what does the data say" and becomes "what happens if we do nothing, and what changes if we act".
Today's storage, today's demand, today's transfer behaviour. The baseline everything else is measured against — and already enough to show where the corridor runs tight before any forecast is applied.
Twenty years of forecast rainfall pushed through the same network, against demand that keeps growing with the corridor. This is the scenario that makes the case — the one that shows a decision deferred is still a decision.
The identical forecast, re-run with interventions in place: new storage where the model says it earns its cost, transfer re-routed, and the flagged reservoirs put under close monitoring. The difference between this panel and the last one is the policy argument.
That third panel is the whole reason the work package was called Actionable Intelligence Policy. Intelligence that only describes a problem is a report. Intelligence a decision-maker can act on has to show them the consequence of their own choices — which means the model has to survive being questioned by someone who has never heard of a raster.
Geospatial Solutions Architect, then Team Leader — I designed the analytical chain, built the reservoir network model and the automated demand tool myself, and led the team through field collection, QA and handover.
Not the remote sensing and not the hydrology — the join. Making satellite layers, thirty custodians' records and a growing region's demand agree with each other well enough that a policy could rest on the answer.
A flagship reference application for THEOS-2 — and, for the decision-makers, a screen where doing nothing has a visible cost and an action plan has a measurable one.
Where the ground truth was learned
GIS/CAD Engineer on hydropower programs across Southeast Asia — topographic mapping, relief models, and conceptual design in ArcGIS Pro, Civil 3D and AutoCAD; GIS-based hydropower potential studies and dam-break flood-impact scenarios; photogrammetry and remote-sensing environmental monitoring; and the regional GIS databases underneath it all.
Five years of work where the answer had to survive contact with real ground. A hydropower scheme is a chain of consequences — rain lands on a catchment, a dam holds it, a turbine converts it, a town is lit by it, and a wall somewhere is holding all of that back. My job was to model the whole chain well enough that an investor could commit to it and an engineer could build it.
This is the scheme a hydropower study has to hold in its head all at once. Step through it — every stage is a different question, and the last one is the reason the others have to be right.
Everything downstream is a consequence of this. Thirty years of satellite rainfall over the catchment, read against terrain, land cover and vegetation, is what tells you how much water this river actually carries — and how much it carried in the worst year on record, which is the year that sizes the whole scheme.
A river you cannot store is a river you cannot dispatch. The dam converts a variable flow into held volume — and the reservoir's shape comes straight from the terrain and bathymetric surveys, because storage is just the geometry of a valley below a waterline.
Water drops through the penstock into the powerhouse, and the drop is the product. Height times flow times efficiency is megawatt-hours — and megawatt-hours are the only thing in this entire diagram that an investor can put a price on.
A cascade earns its money by spending the same water more than once. Rather than follow the river around the mountain, a tunnel takes it under — buying head that the valley would have wasted. Whether that tunnel is worth its cost is a geology question before it is ever a financial one.
The last reservoir sits behind a wall that is beginning to fail. Every megawatt in this scheme exists because water is being held above people — and that is a liability the same models have to quantify, not an afterthought bolted on at the end.
The wall goes, and the stored volume becomes a wave with an arrival time and a depth at every street. Dam-break flood-impact modelling was a core part of my work here — routing the release over surveyed terrain and population density to answer how far, how deep, how fast, and how many people. It is the least commercial number in the study and the one that decides whether a scheme is allowed to exist.
A hydropower scheme is a bet on a river's behaviour for the next fifty years, made before a single metre of it is built. Every layer below exists to shrink one specific uncertainty in that bet — and the model is only worth as much as its thinnest input.
A scheme has to clear all five. One that generates well and drowns a valley does not get built; one that is clean and never pays back does not get funded. The study's job is to find the configuration that survives every test at once — and to say plainly when there isn't one.
A dam, a tunnel portal, a powerhouse platform, an access road — none of them exist in the landscape you surveyed. Every one has to be carved into it or built out from it, and the ground has to be willing. That question sits between civil design, geotechnics and the surface model, and as the GIS and Civil 3D specialist it landed with me.
Excavated out of the ridges to seat the structure. Every cubic metre has a haul cost, a slope-stability question and somewhere it has to go.
Built up across the low ground. If the cut can supply it, the earthworks balance; if it cannot, the difference is imported — and the cost moves.
This is where a feasibility number stops being theoretical. Shifting a powerhouse fifty metres to sit on better rock can change the earthworks enough to change the payback period — which is why the surface model and the financial model have to be the same conversation, not two reports.
GIS and Civil 3D specialist across the study team — building the surfaces, running the hydropower potential and dam-break analyses, and producing the earthworks quantities the cost model depended on.
Everything since has been the same move at a different scale: take messy real-world evidence, build one model everyone can argue from, and give the decision-maker something they can act on.
Five years where being wrong had physical consequences. That is a useful thing to learn early, and it is why I still go and look at the real process before designing a system for it.
Want the detail behind any of this?
These pages cover the outline. If you'd like to know more about the architecture decisions or my role in any of these programs, feel free to get in touch.