An Insurer's Journey to the Cloud
Author:Dan Himmerich, Senior Principal and Insurance Industry Strategist, CSC
Much has been written about the impact of private and public cloud environments on the business of insurance. Analytic workloads necessary to ensure compliance with capital solvency regulations, CRM, Platform as a Service — everything seems to be on the agenda. However, despite the abundance of private and public cloud service availability, many insurers are still struggling to understand where, when and which applications are good candidates for cloud platforms, let alone how to modernize those applications to take maximum advantage of cloud economics.
Key benefits of cloud economics include capital expenditure avoidance, elastic “pay-as-you-go” capacity, and the general price competition between cloud service providers. This makes setting the right foundation — one that helps insurers take advantage of lower pricing due to competition over time — a critical element of an organization’s journey to cloud enablement.
There are three key steps for insurance CIOs seeking to move to an environment of ubiquitous infrastructure:
Step 1. Application Classification: Stratify Your Apps into Tiers
By stratifying applications based on workload characteristics, for example, an insurer can evaluate volatility and rate of change in applications. You can also evaluate the interaction these applications have with other enterprise applications, and the likelihood that “burst” capacity will be needed during product launch, sales campaigns or, in some cases, local or regional disasters.
By classifying systems along an easy-to-understand schema, insurers are better positioned to prioritize application migration to cloud services. This schema organizes applications into one of four tiers. Common tier characteristics serve to define common patterns of remediation or modernization — with the goal of creating cloud-optimized applications suitable not only for cloud deployment, but also for extracting maximum value from cloud economics.
- Systems of Engagement
Systems of engagement typically have the highest level of functional or content churn, as insurers race to drive new, meaningful content into the market, or work to deploy intelligent systems capable of adapting to evolving user preferences — and improving scores for user experience.
- Systems of Analytics
These are closely linked to systems of engagement. They are for insurers that have the infrastructure and systems to dynamically use analytic engines or services, which tend to scale logarithmically (in terms of capacity requirements) as user interaction scales linearly (more events and more complexity quadruple the analytic data points even as the interaction rate merely doubles).
- Systems of Record
Those applications responsible for long-term stewardship of customer, contract, financial and claims data tend to be less volatile, and they are more likely to be scrutinized by regulators for compliance with data protection and data placement regulations.
With decades of relatively nonvolatile historical data under management, these applications are often “late to the game” with respect to migration to cloud environments. (Often the underlying technology inhibits cloud adoption regardless of insurer intent.)
- Enterprise Applications
Finally, those applications that drive human resources, finance, regulatory reporting, correspondence generation and composite risk concentration evaluation (as with reinsurance) are frequently considered too tightly integrated with each other and with other applications (typically systems of record) to benefit from migration to cloud services.
Step 2. Cloud Optimized Design: Develop a Migration Strategy
The move from traditional, owned (or outsourced) infrastructure to cloud services warrants a close look at the design of target applications. A design review — leading to a classification of “cloud-enabled” or “cloud-optimized” applications — can help decision makers prioritize investment and more clearly articulate the business case for moving to cloud services and cloud economics.
For example, in the “systems of engagement” tier previously discussed, the availability of instantly scalable capacity required during regional disasters (consider first-notice- of-loss systems associated with typhoons, earthquakes or man-made disasters) is a compelling argument to adapt these systems to cloud architectural patterns, and to enable rapid scaling that ensures the application is designed to enable the use of scaleout capacity.
Evaluating the design of these applications, and ensuring that sudden increases in transactional volume are engineered into the application design, is a crucial skill for insurance technology managers to master as they journey to the cloud.
Similarly, in a mobile-first world where user experience is king (insurers should take a lesson from the evolution of mobile-first retail in this regard), the intersection of real-time artificial intelligence with dynamic content presentment creates a highly unpredictable data flow and presentment environment.
Not only do insurers have to grapple with unpredictable compute requirements, but they also have to design for huge shifts in data flow into and out of these systems.
Many insurers are just developing the internal talent necessary to design and optimize these kinds of systems — experimenting and then deploying into cloud platforms is a good use case for this emerging class of smart user-experience systems.
Step 3. Remediate Cloud ‘Anti-Patterns’
An anti-pattern is a design element that solves a given problem but, due to changes in the external environment, no longer solves that problem correctly. Such anti-patterns abound in precloud application architectures. To take full advantage of the technical and economic benefits of cloud services then, some amount of application modernization or remediation is essential.
Within insurance applications, several anti-patterns stand out as typical examples of application design that worked well in the era of dedicated, expensive, physical hardware, but are less appropriate for elastic, ubiquitous, virtual platforms.
Application “forking,” or the spawning of multiple compute threads under application control, represents the most common cloud anti-pattern we have seen in the insurance industry. In this anti-pattern, serial elements of the system are executed using a single core, or system processor. However, when a complex task is presented (example: the rating of a complex risk after iterative collection of risk data), it was common in the physical infrastructure era for programmers to fork, or diverge, the logic paths so that many parallel actions could be executed at one time.
In terms of resource reservation — you pay for what you reserve — this anti-pattern requires a high resource configuration in order to “have enough” capacity to complete the process from end to end, including the limited time when it requires 2x, 4x or 8x the baseline capacity. When you pay for what you reserve, this pattern clearly adds cost to the cloud services construct.
Other similar anti-patterns include inefficient use of cache (internal memory used to store data to avoid relatively more expensive input/output actions), resulting in the need to reserve large amounts of memory to ensure availability as and when the application requires it.
In these and other cases of application design not optimized for cloud services, key initial steps toward becoming a cloud-optimized enterprise must be to examine and remediate these and other cloud anti-patterns.
Correcting these types of design problems can have a material, positive benefit on the business case for adopting cloud services, and on the financial rewards reaped by deploying cloud-ready (as opposed to simply virtualized) applications.
Taken together, application classification, cloud-optimized design and anti-pattern remediation are three key steps insurers must take on the journey to becoming cloud empowered.
The CIOs who get this right are the ones who will lead the successful transformation of their organizations to a cloud-empowered environment.