What a Design Authority Actually Does in Insurance Transformation | Cavehill Consulting

What a Design Authority Actually Does — And Why Most Programmes Don't Have One

Ask the post-mortem team on any failed Lloyd's or London Market technology programme what was missing and the answer, more often than not, is some version of: "Nobody was making the architectural decisions." The language varies — "we needed stronger governance," "the requirements kept changing," "the GSI didn't understand the domain" — but the underlying diagnosis is consistent.

The function that was missing has a name. It is a Design Authority. It is absent from most of the programmes that run amber or red in this market.

What a Design Authority is

A Design Authority is the governance function that holds the architectural decisions in a technology programme. It is not a committee. It is not a steering group. It is a role — or a small team — with the authority to make binding decisions about what the technology must do, how it must be structured, and how the implementation must deliver against those requirements.

The Design Authority sits between the strategy layer and the implementation layer. The strategy layer defines what the programme should achieve. The implementation layer builds the technology. The Design Authority defines what "built correctly" looks like and holds the implementation accountable to that definition throughout the delivery cycle.

Three things make it different from a governance structure that uses the same name.

It has binding authority. The decisions are not recommendations. The vendor cannot negotiate around them. The programme manager cannot revise them under timeline pressure.

It stays on the programme. A Design Authority that produces an architecture document and hands it over is a consultant. The genuine function is present from architecture definition through to production delivery. It reviews the vendor's design. It signs off the implementation or sends it back.

It has domain depth. In the Lloyd's market, this means underwriting workflow knowledge — not in general terms, but at the level that determines whether a CDR capture architecture will actually work at the underwriting desk.

What happens without it

Without a Design Authority, the architectural decisions migrate to whoever is most available: the vendor's solution architects, the GSI's delivery leads. Both have expertise. Neither has the incentive to make decisions in the client's interest when those decisions conflict with delivery timelines.

The result is an architecture that reflects what the vendor can build and what the GSI can deliver — rather than what the client's underwriting workflow requires. The mismatch surfaces during user acceptance testing, when the underwriting team encounters a system that does not match how they actually work.

At that point, the programme has two options: accept the mismatch and build workarounds, or reset the architecture. The first option produces a system that the underwriting team will not adopt. The second produces a delay and a cost that the original programme budget did not account for. Both outcomes were avoidable.

The cost of a programme reset in this market runs to 18 months and £3-4 million at the low end. That figure does not include opportunity cost, or the organisational credibility consumed by a programme that had to be publicly reversed.

What it looks like in practice

The Design Authority is the function that holds institutional knowledge throughout the programme lifecycle. In the Lloyd's market context, that means understanding what the CDR capture-at-source requirement means for a specific firm's risk classes. Knowing how the ACORD data model maps to actual placement workflow, not to a generic specification. Holding the GSI accountable to delivering a platform that underwriters will recognise as an accurate representation of how they work — not an approximation of it.

The firms whose programmes have delivered — externally validated Blueprint Two Phase 1 and Phase 2 compliant solutions, live Whitespace integrations, Everest Group Leader-recognised underwriting workbenches — have had this function present throughout. The firms whose programmes have run amber or red have not.

This is not a question of programme management methodology. It is a question of whether there is a senior practitioner in the room who understands both the risk and the architecture simultaneously, and has the authority to make binding decisions about both.

When to bring it in

The optimal point is before the GSI contract is signed — when the architecture decisions are still open and the design can be set correctly from the start.

The second-best point is at programme reset — when the steering committee has acknowledged that the current trajectory is not delivering, and the question is how to recover rather than whether recovery is possible.

The worst point is after the platform is live and the adoption problem has surfaced. At that stage, the architectural decisions are locked into production code, and the remediation is a redesign project rather than a governance intervention.

The diagnostic question that determines whether a Design Authority is needed is straightforward: who in the current programme has the authority to make a binding architectural decision, and the domain knowledge to make it correctly? If the answer is unclear — or if the answer is the vendor's solution architect — the function is missing.

For a diagnostic conversation on how a Design Authority function would apply to a specific programme, contact Grant.Bodie@CavehillConsulting.com.