Context
EUROCONTROL's integrated Network Manager (iNM) runs air traffic flow management for European airspace. It is a safety-adjacent, mission-critical platform under steady pressure to modernise without disturbing the operational system flying traffic every day.
I joined the Unified Operations programme as a senior architecture consultant through ATOS. Unified Operations was the initiative to raise the technical operations side of iNM to enterprise-grade maturity. It covered the foundations an enterprise needs but that had not yet been put in place consistently for iNM: observability, configuration management, software supply chain, and the target operating model that ties those together.
I worked five parallel tracks. Each had its own sponsors and its own scope. The most interesting part of the job was the ground between them.
Mandate
Deliver the technical designs across five workstreams that each closed a gap in the iNM operational foundation. The designs had to be implementable by internal teams after I was gone.
Role
Senior architecture consultant, engaged via ATOS on the iNM Unified Operations programme. I led the Digital Platform design activity until I left the engagement, and contributed as an individual on the other tracks. I worked alongside EUROCONTROL engineers and architects and other ATOS consultants on the same programme. For a short stretch I also acted as head of the DevOps team, which gave me a closer look at the function the target operating model had to describe.
The engagement shape matters for how the work got done. You contribute, you do not own. The artefact is the deliverable, and it has to survive without you in the room.
Approach
Digital Platform redesign. The largest track, and the one I led. A Digital Platform was already in place when I arrived, but it was not operationally viable: a monolith where components shipped on a single version line, no clear upgrade path, insufficient observability, heavy manual overhead, high run cost, and lock-in to a specific container platform. The redesign was the response, structured around a two-phase move. A tactical phase that deconstructed the monolith into independently manageable components and externalised the shared services — secrets, observability, load balancing, identity — while holding a hard constraint of zero impact on the Digital Products running on top. And a strategic phase that shifted the platform to cloud-native managed services, GitOps-driven deployment, and a multi-cloud posture with a second hyperscaler for disaster recovery.
The design work itself had three layers that fit together. An architecture framework written as a set of chapters, each covering one dimension of the platform: security, resilience, disaster recovery, cost, evolution, integration. A modernisation and cost-optimisation strategy that gave the framework a direction of travel and took the run-cost problem on explicitly, with a tiered-resource model per environment and a shared-services shift that drove most of the projected saving. And high-level designs at the cloud-platform and tenant-network layers that turned the framework into buildable artefacts, including concept work on deployment patterns and the sunsetting of the incumbent product-operator model.
Alongside the written design I built a PoC on Terraform, Vault, and Kubernetes to validate the secrets-management and provisioning flows the framework assumed. The redesign also carried an organisation proposal: merging two previously separate operations teams into a single platform competence centre with a common backlog that reconciled the existing ITIL posture with a Scaled Agile delivery model. The team side ran in parallel: job descriptions for the Digital Platform design-and-implementation team and evaluations on the candidate pipeline. The track was in flight when I left; the team I had been building was the one that would carry it.
Observability. The track opened with a strategy question: what stack, and how does it fit with what iNM already runs? I built an Elastic-stack PoC before writing the strategy document. The PoC ran against a representative slice of the platform and answered the architecture question faster than a paper could have. The strategy document came after and carried less weight than the PoC did. I also wrote a short analysis of where Instana could complement the Elastic stack, so the strategy did not foreclose a commercial-tool option the programme might want later.
CMDB. The design anchored on ServiceNow CSDM. That framework choice saved me from defending the structure from first principles. The energy went into the iNM-specific content: Kubernetes and OpenShift class modelling, the technical-services decomposition, and the CI design that would let discovery and automation do real work once implemented. I wrote the design as layered documents: high-level requirements, CI design, and technical-services mapping. Each audience could read the part they needed without having to read the whole thing.
Target operating model. The R&R work was the messy one. iNM is served by multiple organisations and functions. A target operating model across that topology has to survive sponsors who each think their own function is the one that should grow. I wrote the org blueprint, a competence matrix for the iNM digital platform, and the job descriptions for the critical roles: senior SRE, DevOps engineer, operations architect, head of DevOps. The job descriptions were the artefact that travelled furthest. A role written with real depth gets hired against; a role written with generic language gets watered down in recruitment, and the team you end up with reflects that.
Software supply chain. Two HLDs: a Nexus proxy for artifact management, and a Jenkins-based CD toolset for deployments into the iNM environments. The environment model mattered here. OPSTEST and OPS are separated for good reasons, and the CD pipeline had to encode that separation in its deployment flows rather than work around it. I also ran a Safety Support Assessment pass on the CD toolset to check the design against the regulatory posture. In iNM that check is part of the design conversation, not a downstream gate.
The through-line across the five tracks was coherence. Each design had to be internally consistent and also consistent with the others. The Digital Platform defined the environment the other four tracks served. The CMDB class model had to carry the assets the observability stack would monitor on that platform. The observability stack was supposed to read signals from workloads the CD toolset would deploy onto it. Roles defined in the target operating model were the ones that would own the platform once it landed. Move any one of those pieces and the others shift with it. Leading the Digital Platform track gave me direct control over the spine; on the other four I noticed where they leaned on each other and worked the seams where I could.
Alongside the design work, a material share of the role was landing the designs with the right audiences. Each track had its own review cadence, from internal engineers and architects at one end up to CTO-level readouts at the other, with counterparts on the vendor side in between. Executive reviews were a different exercise. By that point the design being right was a given; the question was whether the programme could commit to what the design implied.
Deliverables
- Digital Platform design body of work: an architecture framework written across the platform's major dimensions (security, resilience, disaster recovery, cost, evolution, integration), a modernisation and cost-optimisation strategy, cloud-platform and tenant-network HLDs for the mission-critical environment, and a working Terraform/Vault/Kubernetes PoC for the secrets-management and provisioning flows the framework depended on.
- Digital Platform team build: job descriptions for the Digital Platform design-and-implementation team and evaluations on the candidate pipeline.
- Elastic-stack observability PoC, working against representative workloads, plus a written strategy and an analysis of Instana as a complementary commercial tool.
- ServiceNow CSDM-aligned CMDB design, layered across high-level requirements, CI design, and technical-services mapping, with dedicated modelling for the container platforms.
- Target operating model for the iNM digital platform: org blueprint, R&R matrix across organisations and functions, competence matrix, and job descriptions for the critical roles.
- HLDs for the software supply chain: Nexus proxy and Jenkins-based CD toolset, with environment-specific deployment flows for OPSTEST and OPS, and a Safety Support Assessment view on the toolset design.
What made it hard
The regulated posture shaped everything. Routine-change definitions were a real artefact, not a formality. Maintenance windows were governed by safety assessments. A design that ignored that topology would not land, regardless of how clean it looked on paper. The regulatory shape of the platform had to be read into every track.
The five tracks moved in parallel and drifted apart if you let them. Each had its own sponsors, its own review cadence, its own deliverable dates. Holding coherence across them was a second job on top of the first, and it was only partly anyone's formal responsibility. I did it because the work needed it done.
The Digital Platform track was the highest-stakes of the five. Replacing an incumbent platform in a large regulated organisation is not a decision that gets taken quickly, and commitment to the redesign came in stages. Part of the work was remaking the case for it in forums where the technical argument was only one input among several.
Consulting distance was its own constraint. You can write a design that is technically correct and watch it sit on a shelf. The designs that moved were the ones I spent conversation time on, not just writing time. A good design with a bad review conversation lands worse than an average design with a good one.
What I took from it
Three things stuck.
One: parallel workstreams have a coherence problem that sits above any one of them. Each track wants to be internally consistent. The harder constraint is making them mutually consistent. If no one is watching the seams, the seams come apart, and by the time they do it is expensive to fix.
Two: a running PoC changes a strategy conversation more than a strategy document does. On contested choices, the fastest way to settle the argument is to build the thing. The Elastic-stack PoC did more for the observability direction than the strategy paper that followed it.
Three: a framework pays rent on your behalf. Anchoring the CMDB on CSDM meant I was not defending the structure from first principles. I was defending iNM-specific departures from a framework that was already accepted. That shift in frame saves weeks.
And the residue. Writing for someone else's hands is different from writing for your own. A design owned by you and one you hand off on a consulting contract are not the same artefact. The second has to survive without its author, and that has to be designed into the writing itself. A lot of how I write designs now traces back to that second kind.
Sources (public record on EUROCONTROL iNM and the programme context):