Business Capabilities

A business capability is something the organisation does, or needs to be able to do, to achieve its objectives, described independently of how it is done, who does it and which systems support it. Claim assessment, fraud scoring and payment are capabilities for an insurer; the process, the team and the application behind each can all change while the capability stays. Capabilities are named as nouns describing an ability, and organised in a hierarchy from broad level-one domains to level-two capabilities and selective level-three detail. That stability is why architects use the capability map as the backbone for investment decisions, application rationalisation, service boundaries and team ownership.

A capability is what the business is able to do; a process is how work flows through a sequence of activities that uses one or more capabilities. Claim assessment is a capability. The motor claims process, from first notice of loss through survey, assessment, approval and payment, is a process that draws on intake, survey management, coverage decision, fraud scoring and payment capabilities in turn. Processes change frequently, through automation, regulation or reorganisation, while capabilities remain. Value streams sit above processes as end-to-end views of customer value. For architecture, capabilities are better anchors for service boundaries, because boundaries drawn around processes break every time the process is redesigned.

A capability map is a hierarchy. Level one holds broad domains such as Claims or Fraud and risk; level two breaks each into capabilities such as First notice of loss, Document capture and Policy verification; level three adds detail only where an investment decision needs it. Siblings at every level should be MECE, mutually exclusive and collectively exhaustive, so they do not overlap and together cover the parent. Names are nouns describing abilities, never departments, processes or systems. Starting from a reference model such as ACORD for insurance or BIAN for banking saves time, but it must be trimmed with business owners: NovaBank used 140 of BIAN's service domains, not all of them.

A capability heat map colours each capability on the map according to an assessment, so investment priorities become visible at a glance. The usual dimensions are strategic importance and current maturity, each scored from one to five with business owners, plus performance against KPIs as red, amber or green. The gap between importance and maturity is what matters most: a capability with importance five and maturity one is a critical investment target. Kavach's claims map showed fraud scoring with no supporting system at all, alongside FNOL and survey management, while payment scored adequate and was left alone. It turns a vague request for modernisation into a focused, defensible investment case.

Capabilities give microservice boundaries a stable business basis. You group level-two capabilities with high cohesion, those that share data, language and change together, such as FNOL, document capture and policy verification, into a candidate bounded context, and then validate the grouping with event storming to check that events and terms are consistent within it. Each bounded context gets one model, one ubiquitous language, a stream-aligned owning team and explicit API and event contracts with its neighbours. It may become one service or a module of a modular monolith; Kavach enforces such module boundaries with Spring Modulith verification. Boundaries drawn this way survive reorganisations far better than ones cut by technical layers.

Capabilities are stable because the business need behind them persists even when everything that delivers it changes. An insurer has always needed to assess claims, whether through surveyors with paper forms, a call centre with a legacy claims system, or AI analysing photos uploaded from a phone. Processes are redesigned, departments are reorganised and applications are replaced, but the ability to assess a claim remains. That is why capability names deliberately avoid processes, teams and systems. For architects, stability is the whole point: service boundaries, data ownership and team responsibilities anchored to capabilities need far less rework when the organisation or technology inevitably changes.

Core capabilities differentiate the business and directly drive its strategy; generic capabilities are commodities every organisation needs and nobody wins by doing better. Supporting capabilities sit between, necessary and specific to the business but not differentiating. The classification comes from domain-driven design and drives sourcing. At Kavach, coverage decision, fraud scoring and the FNOL experience are core, so they are built in-house or bought and heavily extended, with the best engineers and the cleanest architecture. Survey management is supporting, built simply or configured. Payments, notifications and document storage are generic, so they are bought as SaaS or managed services, which frees effort for the core.

It reveals gaps, redundancy, fragmentation and legacy dependencies. Gaps are capabilities with no supporting system, such as fraud scoring at Kavach, which relied on manual referrals. Redundancy is several systems implementing the same capability, such as NovaBank's seven separate customer notification implementations, which become consolidation candidates. Fragmentation is one capability spread across systems, such as FNOL handled partly in a CRM, partly in the legacy claims application and partly by email, with manual re-keying between them. It also shows where business rules are locked inside legacy code. Combined with the heat map, the mapping turns into a prioritised list of rationalisation and modernisation work with clear business justification.

Express the roadmap as capability uplifts rather than projects or technologies. Each release states which capabilities will move from one maturity level to another and which KPI will prove it. Kavach's plan puts digital FNOL, document capture and status tracking in release one at six months, automated assessment and fraud scoring version one in release two, and cashless partner integration and recovery in release three at eighteen months. The heat map sets the order, dependencies between capabilities shape the sequence, and each project in the portfolio is tagged with the capability it uplifts. This keeps business sponsors and engineers aligned on outcomes, and makes it easy to drop work that uplifts nothing important.

Industry reference models give a vetted starting point and a shared vocabulary. In insurance, ACORD's capability and information models describe what an insurer does, from policy administration to claims and reinsurance. In banking, BIAN, the Banking Industry Architecture Network, defines a service landscape of several hundred service domains, from customer offer to payment execution, that maps well onto capabilities and service boundaries. Other domains have frameworks such as TM Forum's eTOM for telecoms, and general frameworks such as TOGAF and the Business Architecture Guild's BIZBOK describe how to build capability maps. Use them as a checklist and vocabulary, then trim and adapt with business owners; copying the whole model produces an unusable map.