Engagement · Assessment + Roadmap · Advise · 2018–2020

A federal social-insurance institute whose one IT department carried every priority at once. A tangled estate, parts of it past support, understood only in pieces.

We mapped the estate against the institute's own strategy. That became a costed, priority-ordered modernisation roadmap. The institute then led its first year.

228

technology standards inventoried and classified, from preferred to phase-out

40

end-of-life technologies surfaced and mapped to their replacement blockers

~25

costed roadmap projects, each tied to an organisational goal

2020–2023

roadmap horizon, the sequenced phasing the assessment set

The principle · Preparation

See the whole board before you move. A capability map and a fit score show you where you stand. The roadmap is the harder part: deciding the order of the work.

Section A · The work

What to fix first, and why.

One department, every priority at once

The institute protects the social status of self-employed people, from the day they start a company to the day they draw a pension. Its ICT had just brought development and run together under one leadership. That single department now carried close to two hundred high-priority initiatives, all competing for the same attention, and some of the technology underneath was years past its supported life. Leadership wanted a clear read of the estate, a target architecture, and a plan that said where to invest first and why.

Start from the strategy

The work began with the institute's own IT vision, before anything in the estate was touched. Each vision statement was mapped through a COBIT goals cascade down to the IT processes that would carry it, then matched against what the department actually did. That comparison surfaced the real gaps between intent and capability. Now the rest of the assessment had something concrete to test against: the strategy the estate was meant to serve.

Inventory the whole estate

Through interviews and workshops with the infrastructure teams and the application owners, every piece of hardware and software in the organisation was inventoried. For each one, the work separated two things that usually get blurred: what the technology can do, and what it is actually being used for. That inventory mapped onto a single capability map across people, process, information and technology. Each capability was then scored under-fit, fit or over-fit against the institute's needs and against market practice, so investment could go where value was leaking.

Standards were set with deliberate restraint. Per capability: one accepted standard, plus at most one tolerated legacy alternative. A per-technology deep-dive on suitability, maintainability, lifecycle, expertise and security surfaced the forty end-of-life technologies. Some of those were hard cases. The institute could not simply switch them off: applications pinned to out-of-support servers with no replacement path, where the job is to find a way through.

How the order was set

The gaps, the fit scores and the lifecycle findings fed a plan with two layers. Every candidate was written up as a fully specified project: its own brief, its budget in effort, its duration, the capabilities it touched and the goal it advanced. The order balanced each project's business value against the security risk it carried and how close the underlying platform was to losing support, so the institute could plan a platform's exit before extended support ran out. The projects were then sequenced against a map of how they interlock, so the order respected what depends on what. Out of that came two things: a sequenced 2020–2023 roadmap, the high-level view of where to go and in what order, and the multi-year programme of about twenty-five fully defined, budgeted, scheduled projects underneath it.

Two architects from the same consultancy ran the assessment together. Their skills were complementary, and a two-person team is the usual shape for work of this scope. One was resident full-time on site at the institute; the other balanced it with another engagement. The draft recommendations and the implementation plan were presented, then reworked on the institute's feedback. The institute validated the resulting plan and took ownership of it. The people who would carry the programme had a real hand in shaping it, and the order of investment was theirs to run.

Section B · What changed

What the first year delivered.

The work left the IT organisation with a maintained technology baseline, a shared language between the teams that build and the teams that run, and an order of investment the board could actually weigh. The order was deliberate: ageing platforms were scheduled to come off support before they fell out of it, and the whole sequence respected how the projects depend on one another. The institute then led year one of the programme itself, executing the plan, and retired about a quarter of the legacy estate, roughly a third of the full phase-out target. The rest is multi-year by design. Some systems need replacement funding or rewrites before they can go.

The institute could execute at that pace because security ran as a track of its own, hardened in step with the platform work as API and SOAP protection was rolled across the estate’s services, external endpoints included. Compliance was held at each quality gate against ISO 27001, NIST and the federal cyber standards, so the estate stayed inside its risk posture throughout the rebuild.

~25%

of the legacy estate retired as the institute led year one

The institute came away knowing, every year, what to fund next and why.

A technology estate too tangled to know where to invest first?

MOBIAS maps your whole estate against your strategy and scores where value is leaking. What comes back is a costed order of investment that your board can fund and your teams can own.