How One Insurer Turned a Shelved Capability Map Into a Decision Engine

Key Takeaways

• Build your capability hierarchy to Level 3 before attempting any cross-mapping — Level 1 and 2 are too coarse to support real investment decisions, and going straight to Level 4 buries the team in process detail that belongs in a separate artifact.
• Cross-map every Level 2 capability against strategic objectives, application footprint, and cost; any capability that shows high investment with zero strategic linkage is your first divestment or deprioritization candidate.
• Assign a single accountable capability owner per Level 2 capability, distinct from any application owner or business unit head, and put that name in the model itself — not in a separate RACI spreadsheet nobody opens.
• Run heat mapping sessions with a consistent maturity rubric (we recommend a five-point scale covering process, technology, data, and people) rather than a subjective red-yellow-green vote — subjective heat maps get argued into meaninglessness within two quarters.
• Schedule a quarterly capability model review tied to the portfolio or investment committee calendar, not an ad hoc architecture forum — a model that isn't reviewed against live budget decisions will be stale within a year.

The Trigger: Integration Chaos Without a Shared Vocabulary

Meridian's capability modeling effort didn't start as an architecture initiative — it started as a fight over which claims system to keep.

Six months into the integration, the acquired company's claims team insisted their platform was faster to configure; Meridian's legacy claims team insisted theirs had better carrier integrations. Both were right, and both were talking past each other, because nobody had separated the conversation about the Claims Adjudication capability from the conversation about the specific systems delivering it. Every discussion collapsed into a systems bake-off instead of a capability rationalization exercise. The CIO brought in business architecture not to build a map for its own sake, but to force a structural separation: what does the business need to be able to do (capabilities), versus what processes execute it today, versus what applications support those processes. That three-way separation — capability, process, application — is the single most valuable distinction a capability model introduces, and it's the one most integration teams skip under deadline pressure. Within the first month, the team discovered that both organizations had a materially overlapping Underwriting Risk Assessment capability, delivered through four different rules engines, none of which mapped cleanly to the same processes. That single finding reframed the entire integration roadmap from "which system wins" to "what does this capability need to do, and which delivery mechanism gets us there fastest."

Building the Hierarchy: L1 Through L3, Without Boiling the Ocean

Meridian's team deliberately stopped at Level 3 for the initial model, resisting pressure to decompose every capability down to granular sub-capabilities before it had proven value.

Following BIZBOK guidance, the team defined Level 1 domains (Underwriting, Claims, Distribution, Policy Servicing, Finance, Enterprise Support), decomposed each into Level 2 capabilities (Underwriting Risk Assessment, Underwriting Pricing, Claims Intake, Claims Adjudication, and so on), and stopped decomposition at Level 3 for anything not immediately in scope for integration decisions. This is a deliberate scoping choice, not a shortcut — a Level 3 capability like Claims Fraud Detection is specific enough to map to a system and an owner, but not so granular that it duplicates a process map. The hardest internal debate wasn't naming the capabilities — it was keeping the team from describing functions or org units instead of capabilities. "Actuarial Department" kept showing up as a capability name until the team enforced a naming convention: every capability name is a noun plus an action-oriented qualifier describing what the business can do, never a department or a system. "Actuarial Department" became "Loss Reserve Estimation" and "Rate Development," both of which could exist and be resourced independently of which team or system currently performs them. Meridian also resisted the temptation to build one map for the combined entity from scratch. Instead, they built the target-state capability map first, then mapped both legacy organizations' processes and systems onto it — a pattern that dramatically reduced the political friction of "whose map is this," because neither side's existing artifact was being declared the winner.

Cross-Mapping: Turning the Map Into a Decision Surface

A capability map with no cross-mapping is just an org chart with better vocabulary — the analytical value comes entirely from what you layer on top of it.

Meridian's team ran three parallel cross-mapping exercises. First, capability-to-strategy mapping: every Level 2 capability was scored against the four strategic objectives leadership had set for the combined entity (profitable growth in target segments, digital self-service adoption, expense ratio reduction, and regulatory resilience). Second, capability-to-application mapping: every capability was linked to every system currently delivering it, surfacing the redundancy that had been driving the claims system argument. Third, capability-to-cost mapping, pulling actual run-and-change spend from finance and attributing it to capabilities rather than cost centers — a step most organizations skip because it requires finance and architecture to actually collaborate. The combination was where the value showed up. Underwriting Pricing scored high on strategic relevance and was absorbing disproportionate spend across three separate rules engines — a clear consolidation target. Meanwhile, a back-office capability called Producer Commission Calculation scored low on every strategic objective but was consuming meaningful maintenance spend across two legacy platforms — a candidate for outsourcing or a lightweight utility platform rather than continued custom investment. These are exactly the kinds of decisions capability-based planning is designed to surface, and exactly the kind that never emerge from a systems inventory or an org chart review. This is also where a modeling platform earns its keep over static documentation: heat maps built in a spreadsheet go stale the moment one system is decommissioned or one strategic objective shifts. When the model lives in a connected platform, updating one attribute — a cost figure, a maturity score, an application retirement — automatically ripples through every view built on top of it.

Governance: Who Owns a Capability When No One Owns the System

The model's credibility depended entirely on whether capability owners had real authority, not just a name on a slide.

Meridian assigned a single accountable capability owner to each Level 2 capability, deliberately chosen to be someone other than the application owner or business unit head — usually a senior business leader with cross-functional visibility into how the capability was delivered across both legacy organizations. This separation mattered because application owners have a structural incentive to defend their system; a capability owner's mandate is to defend the outcome, regardless of which system delivers it. Governance wasn't a separate committee bolted onto the architecture team — it was folded into the existing investment and portfolio governance cadence. Capability owners were required to sign off on any technology investment request tagged to their capability before it reached the portfolio committee, and the capability model itself became a required exhibit in every business case above a defined investment threshold. This is the detail most organizations miss: governance only sticks when it's embedded in a decision forum that already has teeth, not when it's a new forum competing for calendar time.

• Capability owner: accountable for outcome and investment priority, not for any specific system
• Application owner: accountable for system performance and lifecycle, reports investment needs to the capability owner
• Portfolio committee: requires capability model exhibit for any investment request above the defined threshold
• Quarterly review: capability owners re-score maturity and strategic relevance, updates flow into the live model

From Model to Decisions: Three Calls the Map Actually Drove

The test of any capability model is whether it changed a real decision — Meridian's did, three times, within the first year.

The first decision was the claims system consolidation itself. Rather than choosing based on which legacy team lobbied harder, the portfolio committee used the capability-to-application and capability-to-cost mapping to select the platform that best supported the target-state Claims Adjudication and Claims Fraud Detection capabilities, with a clear migration plan for the losing platform's unique functionality that the business genuinely needed. The second was a rationalization decision on Producer Commission Calculation — the low-strategic-relevance capability identified during cross-mapping. Instead of funding a modernization project either legacy team had proposed, leadership moved the capability to a shared, lighter-weight utility approach and redirected the freed capacity toward Underwriting Pricing, the high-relevance, high-redundancy capability identified in the same exercise. The third decision was less visible but arguably more valuable: several proposed AI and automation pilots were evaluated against the capability model before funding, and pilots targeting capabilities with low strategic relevance or already-mature delivery were declined in favor of pilots targeting capabilities scored as strategically critical but operationally immature. This is capability-based planning doing exactly what it's meant to do — not generating more projects, but filtering out the ones that don't deserve funding.

Where It Almost Failed: Common Pitfalls Meridian Had to Correct

The model nearly stalled twice, and both near-failures are patterns we see constantly across industries.

The first near-failure was scope creep into Level 4 and Level 5 decomposition before any cross-mapping had been done. A well-meaning team of business analysts spent nearly two months decomposing Claims Adjudication into granular sub-capabilities and activities before leadership had even seen a strategic heat map. The architecture lead had to explicitly halt decomposition and force the team to complete cross-mapping at Level 3 first — proving value before investing further modeling effort. The second near-failure was letting the model become an architecture-team artifact rather than a business one. Early drafts used architecture jargon that alienated business stakeholders in review sessions, and attendance at model review workshops dropped sharply after the second session. The fix was deceptively simple: rename every review session around a business question ("Where are we duplicating underwriting risk work?") rather than an architecture activity ("Capability model review"), and always walk in with a decision framed for discussion, not just a diagram to admire.

Sustaining the Model: From Static Deliverable to Living Decision Layer

The final and most durable shift at Meridian was moving the model off static diagrams and spreadsheets into a governed, connected platform.

In its first six months, the model lived in a set of linked spreadsheets and a diagramming tool — workable for the initial build, but immediately fragile once multiple owners needed to update maturity scores, cost attributions, and application links simultaneously. Version conflicts and stale copies started circulating within weeks, undermining the very credibility the model had just earned. The team migrated to a purpose-built business architecture platform specifically so that capability owners, finance, and application owners could update their respective attributes directly, with every downstream view — the strategy heat map, the redundancy view, the investment tiering — recalculating automatically rather than requiring a manual refresh cycle. The operating cadence that made this stick was straightforward: capability owners re-score maturity and strategic relevance quarterly, ahead of the portfolio committee cycle; finance refreshes cost attribution on the same cadence; and any new investment business case is required to reference the current model state rather than a point-in-time export. That cadence is what separates a capability model that ages gracefully from one that requires a costly re-baselining exercise every eighteen months.

Pro Tips

• Before your next modeling workshop, draft a one-page naming convention document and hand it out at the start — it will save you from relitigating 'is this a capability or a department' in every session.
• Pull actual run-and-change spend by capability, even if finance can only give you a rough allocation initially — an imperfect capability-to-cost map still beats no cost view at all when prioritizing investment.
• Add a required 'capability model reference' field to your investment or business case template this quarter — it forces every requester to at least engage with the model before asking for funding.
• When assigning capability owners, explicitly exclude anyone who currently owns the primary system delivering that capability — write this exclusion into your governance charter, not just a verbal norm.
• Stop decomposition at Level 3 until you've completed at least one full cross-mapping cycle (strategy, application, cost) — resist any team's request to go deeper before that value has been proven to leadership.