As insurers plan their legacy transformation strategies, they need to be mindful of the high degree of elasticity that exists within the ecosystem of technology that supports their business. By elasticity, I mean the tendency of a system to snap back and become firmly embedded in the future-state ecosystem. The reason for this has more to do with the “Glue” that exists between components of the current state infrastructure than with any deficiency on the part of the new systems being deployed.
The systems landscape at most insurers is comprised of the following:
- Several legacy policy admin systems (some of which are over 40 years old).
- A few specialty/niche solutions that were implemented to address specific market and processing needs over the years related to product, billing, commissions, and insurance regulations.
- Operational data stores to house and normalize the information contained in all the systems.
- End-user developed solutions (i.e., MS Access, Visual Basic) that were cobbled together in business areas to offset or supplement high-cost IT investments.
- The Glue: integration, communication, and middleware components that allow all of the above to operate in concert to deliver the core functionality required to run and manage insurance operations.
It is the Glue that will determine the level of elasticity that is embedded in an insurer’s ecosystem. While this is usually the least visible part of the technical environment, it can cause the greatest challenge for transformation programs. Especially in those situations where an integration component performs some of the processing that is usually reserved for admin systems and becomes the authoritative source of truth for data and processing rules. Many of these components were developed before commercially available solutions and standards were developed.
The Glue Problem
Some companies developed custom solutions for online telecommunications middleware running in production that was developed prior to the release of de facto standards in the industry, such CICS, LU6.2 Inter-Region Communications, and MQSeries. Each year, IT leaders seek to replace these custom solutions with their modern-day equivalents, but often they are faced with pushback in the form of, “If it ain’t broke, don’t fix it.”
Unfortunately, these solutions are often critical to more systems than just the one that is being replaced, and at the end of the day, a backward interface gets built rather than incurring the additional cost of upgrading all the other systems.
Over the years, this rationale can result in these infrastructure components (the Glue) becoming more firmly embedded in the cracks between the major systems and, as a result, the path to exploiting new technological capabilities is more complex and costly. I liken it to that famous New England saying, “You can’t get there from here.” This expression is attributed to Maine residents (and usually spoken with a Maine accent) when contemplating the impossibility of traveling directly from one location to another.
Focus on Enterprise Architecture
So how do you remedy this situation? How do you get from the current collection of old systems, barnacle-like infrastructure, and disparate data sources to the new digital, cloud-based world? The answer is by establishing a strong enterprise architecture discipline in your organization: one that bridges both technical and business domains to ensure that business leaders are on board with the issues related to technical debt, the investment required to pay off the debt, and the return on that investment in the form of enhanced business capabilities.
Most IT organizations have a strong IT architecture team, but it is almost as important to have a strong business architecture team. Often, IT organizations can have a difficult time getting the business leaders to understand the rationale for significant spending on new infrastructure technologies.
One of the goals of a business architecture is to tie those infrastructure investments to business outcomes, specifically breakthrough outcomes. Another is to create a methodology for developing business requirements that would provide traceability to a set of committed outcomes related to sales, service improvements, and cost efficiencies. Other goals of a business architecture team include business design, business modeling, services modeling, data architecture, and business and technology alignment.
I built and established an enterprise business architecture team at major insurance company. The team was successful in creating a line-of-sight justification for investments in each technical area by providing linkage to a new business capability and/or cost saving. Over time, the enterprise business architecture team partnered with senior business leaders to develop a comprehensive, five-year strategic investment program that contained traceability between technology investments and business capabilities/results.
For more information on this topic, refer to the recent Aite-Novarica Group research report, Enterprise Architecture Expansion and Key Issues.