How to enable digital transformation in insurance with an API-based software platform

Table of Contents:

• Opening up your business
• Option 1: Open core
• Option 2: Peripheral integration layer
• Option 3: The AdInsure way of digital transformation
• Things to consider when looking at API platforms
• Focus on APIs if you’re serious about innovation and ecosystems

We have written previously about the platforms and ecosystems in the era of digital transformation and how the humble APIs became one of the cornerstones of modern digital business platforms. In this installment on the topic, we will look at different strategies of developing a core insurance system that fits into this background and see how AdInsure helps with achieving the APIfication nirvana across the whole insurance value chain.

Plenty of virtual ink has been spilled on the topic of the importance and power of digital ecosystems. However, there is also a lot of real money being poured into making them real. Our clients' questions about APIs are getting louder all the time and we see that most are including API-related integration requirements into their RFPs. While every business is different and APIs definitely play a more significant role in retail-oriented businesses, this is something every insurer needs to be looking at as the transformation of insurance moves towards ecosystems.

I don't have to tell you that such ventures require not only a lot of development effort and dedicated resources but likely a change of the mindset and culture within your organization. The way I see it, the best course of action is to start with the technology part, so you have a digital technology platform in place as you start your shift towards APIs.

Opening up your business

In general, we see two ways organizations in the insurance industry are tackling the implementation of open APIs in their enterprise IT landscape. Both have benefits as well as drawbacks.

Option 1: Open core

Open core is an approach often used with more recent (meaning not ancient) core systems. The goal is to directly open up the core system and its functionalities using whatever interfaces available. The problem with these systems is that they usually provide very abstract integration interfaces that are difficult and complex to use. This complexity arises from the fact that the core system must support the complete portfolio of the insurance company.

The easiest - and likely the most sensible - way to do that is by relying on generic APIs. However, such interfaces usually sport a complex domain model and are likely implemented using previous-generation standards and technologies such as SOAP (or worse). This complexity hurts your API consumers – your potential ecosystem partners – who will find it difficult to understand and connect to such a system.

Don’t make your customers build their own cars

Let me illustrate why that is a problem. Imagine being a car maker instead of an insurer. A customer (car dealer) comes along, and you say to him: "Here, I have a catalogue of thousands of components. We can build almost any car you can dream of!" That's not a great way to sell cars. Nobody wants to become an expert in car design and manufacturing just to sell or drive your car. They just want to get something done.The open core approach is similar. In this scenario, your enterprise IT is focusing on their internal applications and systems and generically exposes them without considering actual customer needs and value propositions - the customer in this case being whichever partner you want to connect with through your APIs.

Figure 1: An open core system with generic, application-centric APIs. Note how the API structure is abstract, driven by difficult-to-discover and understand code names of products, rating systems and attributes. Even simple validations are impossible to express in a schema for such an API.

This approach is application-centric, meaning that the APIs are driven by the applications making up the core system. While they are well suited for integrations within your enterprise, they are not a viable option if you want to drive collaboration and partnerships with external - and some internal - API consumers who have no interest in becoming domain experts for your system.To create or participate in an ecosystem that delivers value and attracts partners, you want to build customer-centric APIs. These are interfaces that are driven by actual, individual use cases that should present some clear value to you and the partner.

So maybe a different strategy is in order?

Option 2: Peripheral integration layer

Another option is to develop an integration layer comprising of external peripheral systems that expose customer-oriented APIs to the outside world on the one hand and integrate with the core system on the other.

In IT-speak, this process is called decoupling and appears sound from a purely IT-architectural point of view. Put very simply, it means that you connect two systems or components without connecting them directly. While it is likely the only reasonable choice when dealing with an old legacy core, it brings many disadvantages in terms of the business value proposition.

This approach requires you to distribute and often duplicate business logic and, with it, the knowledge of implemented insurance products and processes not only in terms of development artifacts (the applications you deploy) but also - more importantly - in terms of teams developing and managing all these systems. All this slows down your time to market for new products and hampers your ability to innovate and communicate clearly with partners.

Figure 2: Diagram of building customer-centric APIs through peripheral systems. Note how the dedicated peripheral systems can provide a better API experience for your partners, but with the cost of having to buy or develop - and worse - maintain multiple systems.

Now that we've discussed two possible strategies for APIfying your business, let's compare them side by side:

Looking at this table, you can see that both approaches make it hard to integrate your products and services into broader ecosystems and open up your business to external partners.

Now - what if you could have something that would give you the best of both worlds?

Option 3: The AdInsure way of digital transformation

These were the issues we looked at when we started developing the latest generation of AdInsure. When we talked to our customers and looked at all major insurance companies, they were clear that they want a flexible system that supports their digital transformation strategy with APIs. It is all about building digital capabilities for better business outcomes; participating in new business models, improving customer experiences, and making integrations with service providers and partners easier.

In response, we set out to build a platform that would make it possible to implement core functionality that would be directly exposed through customer-centric or use-case-oriented APIs out of the box - without having to build, deploy and manage custom peripheral systems.

This would come into play no matter how exotic the use case. Maybe you want to create an innovative Personal Accident product that would integrate with a fitness mobile app? Or perhaps you want to build or participate in an Underwriting-as-a-service ecosystem? How about hourly or pay-as-you-go car insurance? Adjusted premiums for safe drivers? Flexible insurance policies just for freelancers? AI-powered underwriting for Commercial insurance? Integration with smart home devices for comprehensive protection?

That is the cool thing about APIs. They make it possible to create completely new products by integrating your core systems with external features, such as smartphone usage statistics, smart home sensor data, artificial intelligence or anything else.

Figure 3: Diagram of customer-centric APIs from the (AdInsure) core. A simple architecture providing you with developer-friendly APIs that are generated from and driven by product and process configurations. Notice how the API is explicit and essentially self-documenting, clearly communicating its use-case.

Give everyone the power to create APIs

So how did we go about this? We did it by creating what basically amounts to an insurance-business-focused developer platform - the AdInsure Platform. It is a set of frameworks that formalize the approach to developing insurance products and all insurance-related business processes. Since it is a "developer platform", it must support the whole development lifecycle with the help of a powerful configuration tool. AdInsure Studio as a low-code tool allows insurance domain experts to develop insurance products, business processes and APIs on their own.

Yes - you have read correctly, insurance experts such as business analysts, product developers, actuaries, even underwriters can build APIs to some degree as well if you arm them with a proper, business user-oriented tool. And that is exactly the idea behind AdInsure Studio.

The other secret ingredient provided by the AdInsure Platform are automatically generated APIs. After insurance domain experts configure insurance products, process workflows and data models through AdInsure Studio, the platform generates resulting RESTful APIs, described using standard OpenAPI definitions. Here is an example from AdInsure Studio for a travel insurance quote process:

Figure 4: Image - from sales quote configuration to a RESTful API with no additional effort. Note the high fidelity with which the API represents the configured model of the quote – in terms of data types, value enumerations and simple validations.

Simply sharing your APIs with external consumers

It's important to note that the generated API is highly product-specific. It is a high-fidelity representation of the quote data model configured in AdInsure Studio. The API is created with automatic input validations, such as required attributes and allowed values. The API specification is generated as an OpenAPI/Swagger definition document.

After you generate your API, you can share the API specification with your partner - the API consumer. They can immediately start building their part of the solution and provide some feedback quickly. Not only does this approach accelerate the time to market, it also gives you more information you need to iterate your products and services.

After this configuration is published to the target runtime environment, the API endpoints are activated and usable in that environment.

Let's return to our comparison of APIfication approaches and add AdInsure to the picture:

Things to consider when looking at API platforms

First, identify your business needs and your ecosystem and partnership aspirations. These will guide you as you consider the following features and benefits when buying or building an API-enabled core platform.

1. Open standards and protocols

OpenAPI specification is a good option for APIs. It is a modern yet well-established standard for REST APIs. Note, however, that not all partners will be able to adopt APIs immediately, so your back-end platform should be flexible enough to offer alternative processes and interfaces, such as batch imports through Excel/CSV files.

To remain flexible in that regard, AdInsure Platform features an integration framework for building ETL (Extract-Transform-Load) processes through configuration in AdInsure Studio. Use these ETL processes to import new business and automatically drive processes that you have configured before (such as the travel insurance quote process from our example)..

2. Standardized interfaces

If you want to grow predictably, you need to create a system with standardized, consistent interfaces. This means that your APIs should comply with your internal standards and act predictably regardless of who is building and using them. You need to do the work to ensure that once your partners learn to use one API, they will find it easy to work with everything else you offer.

There are two strategies to achieving this consistency:

• The difficult one: establish strict development standards guided by a solid and dedicated API architect role and coupled with good quality control. This is a tightrope act as you also have to leave business stakeholders as much freedom as possible to make sure you stay customer-centric.

• The easier way: implement software frameworks and tools for API development that strictly formalize API development.

en we developed AdInsure, we took the second approach. The general structure and look-and-feel of the APIs are always the same since APIs are generated by the platform and not hand-crafted individually.

3. Modularity

You want to remain agile in your insurance product development so you can easily respond to market changes. Modularity addresses this challenge. A modular platform enables you to develop products and related features in isolation and deploy them individually, without affecting other parts of the system when you do so.

In AdInsure, features such as insurance products, sales and claims processes and different integrations are developed using the platform's configuration capabilities. Each product, process or integration use case can be published individually to different target environments from testing to production in a managed way, using AdInsure Studio - with no production downtime needed.

4. Reuse

Often an insurance product offered for different markets or through multiple channels means you just add small variations of the same general structure. Or maybe the structure is the same, but the workflow is a bit different. These small changes can add up if you must reimplement entire products just to accommodate these variations. You also don't want to end up managing and testing the same changes multiple times.

AdInsure Studio can be used to create components that serve as reusable pieces of product configurations. A drag and drop interface drives adoption among non-technical users making it easier to experiment with new product configurations. It allows you to get products ready faster and to iterate more often when you receive feedback.

5. Managing the complete lifecycle

Development is just one step. You should also have support for testing and documenting as well as managing deployment to different environments. Another important part is how the platform allows you to change your products and by extension - APIs in a controlled way so that you don't break existing API consumers.

Testing is really that important. We built in support for live testing of APIs into our AdInsure platform. It can give you or your partners a complete sandboxed environment in a matter of minutes through the magic of Docker containers.

Focus on APIs if you’re serious about innovation and ecosystems

There really is no question anymore about whether you need to APIfy your business. The issue remains of how to go about it. While this depends on how far along the digital transformation journey you are, your business requirements and your technology situation, you still need to consider the best approach. You could go for a system that's simple to roll out but complex to consume or a more difficult to manage system that delivers a better experience.

However, there are other options. For example, automated generation of APIs allows you to easily create new products and then expose them in a user-friendly and effective way. This is what AdInsure delivers coupled with a powerful configuration tool AdInsure Studio that accelerates your product development while also keeping it fully accessible to your entire ecosystem.I believe that with the approach we took, we enable insurance companies to solve the technical side of the APIfication problem. Truth be told, this is probably the easy part – at least if you are an established insurer. The difficult story being the cultural shift to align your organisation with the reality of having to play in the world of digital ecosystems.

But with the insurance technology primed and ready with AdInsure – having the ability to quickly create new products and processes and automatically expose them through APIs – you give yourself the freedom to start with small experiments or try new ideas internally or with your partners - solve small problems where you know you will get something in return, be it financial, social or otherwise. Through this experimentation you will be able to improve the “digital IQ” of your company and attract new talent, partners, and finally - customers.