Many insurers run claims, policy administration, billing and vendor management on systems that were built or bought at different times and never designed to work together. Staff re-key data between them, reports take days to assemble, and every product change becomes an IT project.
The usual response is to shortlist new platforms. That is often the wrong first step. Insurers that choose a platform before settling their architecture tend to replace one set of silos with another.
What should modern core insurance systems do?
Whatever platforms an insurer chooses, the business capabilities they must support are well understood.
Claims management. An integrated claims capability administers, adjusts and reports on claims from first notice of loss to settlement. It should streamline workflows, give adjusters a single view of each claim, support diaries and follow-ups, and let users build their own reports on transactions and losses without waiting for IT.
Policy administration. An end-to-end policy capability tracks, manages and issues policies, handles endorsements and renewals, and supports configurable billing rates and invoice descriptions. Real-time policy reporting lets underwriters and managers make decisions on current data rather than last month's extract.
Vendor cost control. Insurers spend heavily on external parties such as legal firms, assessors and repairers. Transparent controls over invoices, rates and approvals, with analytics across vendors, keep that spend visible and defensible.
Time management. Where staff or panel firms bill time against claims and matters, a cloud-accessible time and expense capability, usable from a computer, tablet or phone, supports split billing and links time to clients, projects and assignments.
Modernised, these capabilities share data rather than copy it, and they expose that data for reporting, analytics and customer channels.
Why does choosing the platform first go wrong?
Platform-first selection usually starts with vendor demonstrations. Each platform looks capable in isolation, and the decision is made on features. The problems appear during implementation.
- Overlapping capabilities. Two platforms both want to own the customer record or billing, and nobody decided which one is authoritative.
- Integration as an afterthought. Interfaces are designed late, under time pressure, and become fragile point-to-point links.
- Customisation creep. The business discovers its processes do not match the platform and asks for changes that make future upgrades expensive.
- Data migration surprises. Legacy data quality problems surface late and delay go-live.
- Unclear ownership. Without agreed principles, every design decision becomes a negotiation.
None of these are vendor failures. They are architecture decisions that were never made.
What does an architecture practice do before platforms are chosen?
An architecture-led approach answers the structural questions first, so that platform selection becomes a test of fit against a known target.
- Map business capabilities. Describe what the insurer does, from product design to claims settlement, independent of the systems that do it today.
- Assess the current landscape. Record which systems support which capabilities, where data is duplicated, and where integrations are fragile or manual.
- Define the target architecture. Decide which capability each future platform will own, where master data will live, and how systems will integrate, for example through shared APIs or an integration layer rather than direct links.
- Set principles. Agree rules such as configuration over customisation, a single source of truth for each data domain, and security and privacy built in from the start, including Protection of Personal Information Act (POPIA) obligations for policyholder data.
- Plan the transition. Sequence the change in stages that each deliver value and reduce risk, rather than a single replacement of everything at once.
- Select platforms against the target. Evaluate vendors on how well they fit the target architecture, integration model and principles, not only on features.
This work also gives the board and executive committee a clear, costed picture of the change before major commitments are made.
How does this help after go-live?
An agreed architecture keeps paying off once new systems are running. New products can be launched through configuration. New channels, such as broker portals or customer apps, connect through the same integration layer. Reporting draws on consistent data. When a platform eventually needs replacing, the change is contained because its role and interfaces are clearly defined.
What MITS Institute does about it
MITS Institute has advised organisations on business and technology since 2010. Our enterprise architecture practice helps insurers map capabilities, assess their current landscape, define a target architecture and select platforms for claims, policy administration, vendor cost control and time management against it. Read more about MITS Institute and the industries we serve.