A federal health insurer whose leadership wanted more value from architecture and brought MOBIAS in to deliver it, with a software-centred function and no IT strategy yet to steer by. Two pieces of work were waiting. Which one came first was the real decision: set the strategy, then build the practice to realise it.

The institute insures the health and disability cover of millions of people, and its architecture work sat close to the software it produced. Its leadership saw that architecture was not yet returning the value the organisation wanted from it, and acted: the CIO brought MOBIAS in to put that right. The function was software-centred and the architects were carrying more requests than it was built to hold, and there was no IT strategy yet for the architecture capability to serve. That was the value gap leadership wanted closed. Before any staffing decision, one question came first: what should the team be steering toward?

How you organise an architecture function depends on the strategy it has to serve. The processes, the roles, the structures, even the solution and infrastructure architectures themselves all take their shape from the direction the function is built to carry. Building the practice before that direction existed would have meant guessing at its shape. So the early work was done with the incoming CIO: a pragmatic IT strategy on a COBIT base, set together, that the rest of the mandate could realise. The posture it chose was operational excellence: do the architecture work that earns its keep, and let the rest go. That choice was concrete on the ground. Reviews ran through a pair-reviewer model that two architects could turn around quickly, in place of the long formal review boards that slow a small team down. ArchiMate modelling was kept to the purposes the strategy actually defined and to the depth there was budget for, so the practice modelled what served a decision and stopped there, rather than mapping the whole estate for its own sake.

A strategy earns its keep when it makes a difficult call decidable, and here it had to. The first move was to write down everything the CIO wanted an architecture capability to do, then set that list against the capacity actually on hand. The two did not match. Closing the gap meant a choice the strategy and the budget had to settle together: add capacity, or defer some responsibilities and accept that a few needs could not be met yet. So the work was prioritised, and the prioritisation is visible in the deliverables as staged groups, a first to do now, a second and a third to follow, and a set held for later. The capability itself was put on a proper footing. The mandate secured a funded, standing architecture function with its own roadmap, defined responsibilities and expected outcomes, in place of a part-time community of practice. That footing follows from what architecture is for. If it has to look ahead and plan where the IT capabilities are going, keeping a technology radar and a vision the organisation can adapt, it needs a home of its own to do that thinking from, beyond the project and portfolio work where the day-to-day already lives.