Would you want the CIO of your organization to be your go-to Agent? You are probably thinking that this is a really dumb question. And you’re right. But sometimes dumb questions surprise the right answer out of people. In my past as a Chief Architect of a Fortune 500 insurance company, I would ask dumb questions to help people to relate to new concepts, ideas, and principles.
The correct answer is “absolutely not.” For starters, a CIO should be a technology visionary…an agent should be able to sell anything to anyone.
Ok, maybe those are a little too boiled-down, but the reality is that an agent’s job is to produce great sales and service to enable the policyholder to feel confident that their risks have been properly covered and a CIO looks out for the company they work for, utilizing technology and processes to minimize cost and enable employees and agents or brokers to do their job the best they can.
One is behind the scenes and one is front and center. One needs to be nimble, adaptive, and a people-person. The other being consistent, stable, and tech-obsessed. Hopefully, you can figure out which is which. This isn’t to say that CIO’s shouldn’t be nimble or focus on relationships, but their true value is consistency and enablement. And you clearly wouldn’t want an agent that doesn’t follow standards or has no consistency, but they should primarily be great at creating an incredible experience with a wide variety of customers.
The right person (and system) for the right job
If you are still nodding your head, and not nodding off, I would pose these questions:
- Why would a core system vendor provide the best experience?
- Why would you enlist a low-code provider to build your core systems?
- Why would a content system be ideal for building applications with workflow?
These questions aren’t easy to answer. They often require going down additional query-laden rabbit holes to find the fundamental truth.
The broadest answer, however, is that you wouldn’t. Insurance systems have a lot of history as to how they got where they are. Using one system to rule them all is not an approach that is maintainable, robust, or even cost effective. Systems, like people, have different specialties for a reason. An Agent and a CIO could swap roles in a pinch, but neither would be the best person for that job. So, stop listening to the sales pitches that say, “We can do it all!” and start asking them, “Sure, but what do you do best?”.
Brief History of Insurance Systems
Core systems were meant to provide an insurance company an automated way of managing policies, claims, and bills. At first, one software covered all these bases. However, internal users quickly realized that they had different departments that had different workflow needs. Out of this we received specialized offerings from software companies – so then we had a billing system, a claims system, and a policy administration system (PAS). The separation of these was great, but then separated integration became a challenge. Sometimes a company would offer all three, which was functions were from the referred to as the core suite.
Fast forward to the age of modern desktops. Agents needed a way to automate their entry of events around a core suite. Sometimes, carriers were so innovative that they provided a desktop application that functioned as a typical client/server app with the mainframe being the server. This created a separation of workflow and a true separation of concerns. This approach helped agents and brokers do their job by enabling them to follow the best sales process and not conforming to the core system needs.
In the modern age of computing, real-time systems were needed and so entered the big boys on the block; Guidewire, Duck Creek, Majesco, Insurity, to name just a few. These companies enabled real-time interaction with events on the policies and allowed companies to buy parts of their platform and integrate with other systems. But one key thing happened, they tightly coupled the user experience to the workflow needed to process events on a policy. This does not allow agents to have a truly differentiated workflow.
Platforms for insurers
Novarica published a report – DXP and aPaaS for Insurers: Overview and Prominent Providers. It offers up solid data as to why there are options for carriers to purchase.
What you won’t find is a way to break down that data to determine which way your company should go. Luckily, that’s what I’m here for.
The market is being flooded by experience solutions, but most fall into the two categories listed in the Novarica report, Digital Experience Platform (DXP) and Application Platform as a Service (aPaaS).
DXP falls into two sub-categories, Horizontal and Insurance. Novarica points out that these horizontal platforms evolved from content management platforms such as Sitecore and that the insurance platforms have evolved from what we traditionally think of as the agent- or broker-facing applications when purchasing a core insurance system like Guidewire, Duck Creek, SAP, and Insurity.
aPaaS may seem like a new contender on the block, but it has been around for a long time. These systems have been known as Rapid Application Development (RAD), code generators, and other weird names. Only in the past decade has this market truly matured to be able to enable the Enterprise. These platforms enable companies to build secure, scalable, and maintainable applications, while still following proper IT and development best practices. They are now more well known as low-code and no-code platforms.
Scratch that build
But what Novarica doesn’t mention in their report is building from scratch. Why? Because any company that has implemented DXP or aPaaS will tell you that traditional experience development in .NET, Java, HTML, JavaScript takes too long. It is also very difficult to hire top software engineers into insurance companies to ensure that the code you build is maintainable, reliable, secure, and scalable.
As a life-long software engineer, I love to build things from scratch, but now that’s just a hobby. The job as a software engineer at an insurance company is to utilize engineering processes and thinking to formulate solid technical solutions to problems. — I implore you to stop letting your best engineering talent just be code monkeys.
The world has an immense problem and it is even more challenging in insurance – available software engineers are a rarity. And even worse, ones that use their engineering to solve problems instead of just programming code, are about as easy to find as an actual unicorn.
You must look at the strengths of the IT department at an insurance company. Most are insurance experts in their own right. Do you want to really apply that talent to building everything from scratch, or manage that risk by getting solutions that enable IT-insurance experts to differentiate where they need?
I really think that no one should build from scratch anymore, there is efficiency in buying a platform and using that to fit your needs. Utilize your best Engineers to solve difficult problems around the platforms.
Go “as a Service” when you can
The term “Best of Breed” was heavily overused in the insurance industry. It roughly meant that you were willing to pay a ton for all the best core policy, claims, and billing systems out there, only to spend a fortune on integration. Best of Breed wasn’t just overused – it was the wrong term altogether.
Best of Breed SHOULD have meant using the best software and tools available to meet your business needs. There is a slight nuance in this. It doesn’t mean using the best systems out there, it means utilizing the best thing to solve a specific problem.
But that must have an underlying architectural principle. The system must come with a solid API layer. Systems should have the ability to publish or consume fine- or coarse-grained services. With this ability, you can enable that system to do only the things you need it to and nothing more. By looking for solutions that have a good API layer but maybe not the fanciest of other features, you will create the ability to reduce long-term expenses by picking made-for-purpose systems. It’s a big plus if that system can easily plug into an Event Driven Architecture.
I’m not here to tell you which systems are best for you, but the way to talk about this separation of functionality is by using the common “as a Service nomenclature,” such as Policy as a Service, or Claims as a Service, or Content as a Service. Yes, I said content as a service.
When thinking of separation, use microservice architecture principles and break things apart. Ask yourself, could this be used somewhere else? If the answer is yes, make it “as a service.”
For example, by having a true content system, the business can own the data, control who can consume that data, and decide how they would like that data presented. That content might be owned by many parts of the business, but the team responsible for the brand and experience would be able to decide on where to use it without enlisting an army to have many meetings about it. Another scenario might even be to break apart your Policy as a Service to the type of policy, life versus P&C.
This architecture not only allows you to follow a more inexpensive approach to Best in Breed but enables flexibility to add or remove components to your architecture. How often do you feel like you have paid too much for some of the technology you own in your own life? Does your vehicle have OnStar? Have you ever used it? That is an additional cost your vehicle manufacturer has added, and it trickles down to you, the consumer…just to go unused.
Insurance technology is in the same boat, there are bells and whistles that you will never know exist or just don’t do what the company said they would. You are paying extra for all of that. The approach I just gave you (for free😉) allows you to select more purpose-built systems or even smaller, lesser known systems at a fraction of the big guys. Implementation is also faster and cheaper with less “robust” systems.
Fitting the Pieces Together
Just because a company says they “can” do something, does that mean they should? I’ve harped on that through this whole article, and if you take away nothing else…the answer is probably not.
In the Novarica report, they show the relative strengths of different experience solution types. Clearly this shows that if you want a great user experience that integrates to processes and has great workflow, aPaaS is the optimal solution.
In the low-code space, when you create an application, it is a build. It is just a build that has a better framework to create applications quicker. Where you need true differentiation (in the experience layer), remember that low code is not no code. With low code, you have the ability create custom widgets inside the framework that suit your specific needs and utilize the platform the way it was meant to run.
As I have explained, your experience layer should not be your content management system, that data should come from your Content as a Service Platform, nor should it be the place that houses your insurance business logic, save that for the Policy or Claims as a Service platforms. Allow the companies that received four little square block things (read the article) in UX and Process Integration to focus on what they do best, experience.
By doing this, you will have a differentiated experience that you can fully control and own, but the processing speed and efficiency that the core systems provide.
You don’t want your CIO to be an Agent, you don’t want your Agent to be an Architect – an organization runs better when people are in roles where they can function to the best of their abilities. Apply that same thinking to building your core system – look for as-a-service platforms that are the really are the best at a specific function.