Is your insurance organisation in layers or silos

The points I make are around the difference between the customer’s view (i.e. how they see an insurance company,) and the internal view, where “everyone knows” the different silos that are needed to build insurance “products”.

We initially developed the middleware layer in there as a kind of stop-gap arrangement. Its purpose was to let businesses evolve their customer experience layer without having to replace all of the back office systems that are currently in use. It does a good job of that, insulating the customer from outdated interactions and inflexible user journeys.

But as I increasingly get involved with more and more policy administration systems (and other horrors that “some” software houses inflict on the innocent), the more I think that it is a key component, or, if not middleware, its equivalent the API.

“Anyone who doesn’t do this will be fired. Thank you; have a nice day!” Jeff Bezos
An API (or Application Programming Interface to give it its proper name) is a standard way of using a service; think of them as ways to get things done whilst hiding the complexity. For example, if you want to buy a book you can go to Amazon, add it to your basket, click buy and the next day your book arrives. You’ve given Amazon the book title, your credit card, address etc. and the return from that API call is a book delivered to your home.*

This is important even if you are not looking to insulate existing systems, but are putting in new systems. The reason comes down to the difference in needs of the various layers in the stack.

'RAS' isn't inherently evil

The different requirements businesses now face from the customer and internally I think can be directly compared to the Pioneer, Settler, Town Planner model (by Simon Wardley derived from Robert X Cringley). This recognises the differing needs of different organisations. Pioneers need to be lean, adaptive and just about work, settlers have less need for speed and longer horizons and town planners need things that just work.

If you are choosing a portfolio administration system for your business, you want it to last. You probably want to run it for more than 10 years, and it has got to have those three key features: Reliability, Availability and Serviceability (RAS). Those are clearly town planner needs, and not pioneer needs.

The customer experience end of the stack is a very different matter, as this is constantly changing. New browsers, new devices, new attitudes, new customers, whole new layers of software and intermediation, VR and AR, AI interfaces who knows what else. That’s without factoring in the people issue where fashions, fads and expectations are constantly in flux. So it needs to be very amenable to change and flexibly support many physical interfaces. Sounds like a pioneer model, right?

Sadly, instead of recognising and embracing this duality, I see many vendors pushing solutions that purport to be the best of both, and therein lies the risk.

Whenever I see a quote and buy system or PAS  that promises a great front-end web interface, my heart sinks because the cultural differences between pioneers and town planners make it very hard - if not impossible - for this to happen. The cultural differences extend way beyond just the creating of the software. They are baked into the organisational structures, how people are rewarded, what success looks like, the language and behaviours the whole mindset. They're not bad people, they just look at things differently.

It’s not just on the supplier side, if you are trying to select a front to back office system, the teams you need to get together to do this will have opposing needs and approaches, this means you will have to compromise in ways that arguably remove your ability to innovate and differentiate in your customer's eyes. In regulated industries like insurance, back office needs will always trump customer experience ambition, and other industries will have their own challenges.

Layering in practice

Which brings me back to middleware and APIs, the layer that allows you to have the best of both worlds without compromise. Having a clean, well defined and extensible interface lets all parties work together to get the best back office system and the best front office experience for their needs. Changes to the web interface can be made without changing any back end code and new devices can be implemented without changing existing web interfaces. New products and service can be created by recombining APIs in different ways.

So next time you are thinking of updating any software in your organisation that crosses the boundary into the customer's world, or listening to another software vendor telling you how they can do it all the front and back end work, take a huge pinch of salt and ask them about their API layer. My advice is to get experts in to do the customer experience layer as it’s your competitive edge and how you can differentiate your offer in a very crowded world.

* I am using Amazon as an example here, as they are an example of what can happen if you take this whole API thing seriously. Amazon Web Services is their internal APIs repackaged as a service, and Jeff Bezos said in a famous email mandating the use of APIs at Amazon “Anyone who doesn’t do this will be fired.