INTRODUCTION
One question I frequently get asked by insurance companies is if they should buy or build their software applications. I liken this to running a restaurant. You need to answer, ‘Why do people want to eat at your restaurant?’ Is it because of the way you have grown your own herbs, vegetables, and other ingredients? Or is it because of the way you have assembled, prepared, and served the ingredients? Most likely, the answer will be somewhere in between these two extremes. As such, the buy-versus-build question is a good example of a false dichotomy. It’s not either completely buy or completely build, but rather somewhere in between.
THE SWINGING PENDULUM
Some of the larger insurance companies started buying mainframe computers in the 1950s and had to write their own insurance applications. With the creation of COBOL in 1959, it became easier to create their own applications, but there was still a high entry barrier, and instead, many insurance companies continued to rely on paper processes.
In 1962, IBM created a life insurance system called Consolidated Functions Ordinary, whose name I’m assuming had very little input from their marketing department. This application was given to customers when they bought IBM’s hardware. Now, insurance executives could ask, ‘Why are we building our software instead of buying it?’ Packaged software made it easier to level the playing field, but you could never get ahead of your competitors just by using it. And in fact, many large-scale implementations of packaged software were expensive to execute and difficult to implement, which resulted in some of them ultimately failing.
With the advent of cloud platforms, modern programming frameworks, low-code platforms, and better data-handling tools, the pendulum began to swing back towards the build side, but only in part. This time around, insurance companies are building only the components they need instead of full insurance platforms.
REASONS TO BUILD
Agility
With some packaged software, it can be difficult to have the business agility that is required. When you find that packaged software – and not your own business processes – are hindering your ability to react swiftly to market changes, to gain back some agility, you can build your own components, either from scratch or by leveraging a low-code platform.
Functionality
Packaged software covers a majority of the requirements most insurers have. However, there may be times when packaged software can’t meet your needs. In these instances, you might want to build, but only to enhance the packaged software, not to replace it. By building separate components instead of customising the entire software, you can alleviate some of the challenges presented by customisations when the time comes to upgrade.
Competitive advantage
Finally, if a majority of insurance companies is using packaged software, then you will need a way to differentiate yourself in other ways. For example, if the packaged insurance software supports only annual or one-off policies – and you want to offer on-demand or weekly subscription insurance – it may give you a competitive advantage to write a bespoke application to provide this capability.
HOW TO BUILD
Identify what you’re going to build
First, you need to identify what exactly you’re going to buy and which components you’re going to build. For instance, you most likely would not build your own postcode lookup mechanism, but you might want to build your own customer portal. It’s also important to have the future in mind when building, which includes a focus on componentisation, microservices, and connectivity.
Choose the right technologies
Once you know what you’re going to build, you need to know what you’re going to build it with. There are a number of modern technologies that you can choose from: Azure, AWS or Google Cloud, serverless or containers, Python or Go, React or Angular… Additionally, there are a number of low-code platforms you can leverage for some simple functionality. Choosing the right technologies carefully will ensure that they will work together well.
Choose the right partner
Unless you’re an insurance company that was ‘born digital’, there’s a high likelihood that you won’t have in-house expertise in all of the modern development technologies. In this case, it would be wise to get a partner that can help you with your software development and to navigate some of the pitfalls.
SUMMARY
In this article, we’ve explored when and how you should build instead of buy. As the technology lead for Insurance at Endava, I am seeing an increasing trend back towards building, but only for parts of an insurance platform. If you’re looking for a development partner to help you build components of your insurance platform, please do contact us. We would be happy to take your order.