(Image credit: Michal Jarmoluk.)
Customer builds were a common approach to providing core policy, billing, and claims capabilities until competitive core vendors emerged in the early 2000s. The greater flexibility, implementation speed, and speed to market those systems provided—along with the use of technologies that often required degrees in computer science to provide—convinced CIOs to switch from build to buy. Nevertheless, there are still some situations in which building can be better than buying.
Reasons to Buy
There are myriad reasons to buy software rather than built it. Vendor solutions can be evaluated against each other and for fit against a carrier’s requirements. Market-leading software vendors have optimal organizations and expertise for designing software and they are well versed in best practices—it’s what they do. Furthermore, those best practices are honed by experience in the industry as a whole, not with a specific carrier, so carriers may discover better ways of doing business as a result. Finally, buying a system allows carriers to focus on their core business and on building ancillary solutions that add competitive advantage, rather than core plumbing, which doesn’t.
Building: The Pros and Cons
The strongest case for building a core system is when there is no feasible alternative. This can occur if there’s uniqueness to a carrier’s business that the market doesn’t support well, though this is rare given the competitive nature of the vendor marketplace today. A very simple business that doesn’t warrant a heavyweight system—or the converse, a need for massive scalability, as among the very largest insurers—is another potential reason to build. There is also an argument for building where it can provide a competitive advantage, as in customer-facing digital innovations, or product or technology innovations like microinsurance, AI, or cloud. Finally, building can avoid some vendor lock-in, but it’s almost impossible to avoid using off-the-shelf software of some sort and many of the benefits of buying can outweigh the risk of lock-in.
CIOs who think some of the above reasons to build apply to their organizations should consider some further drawbacks to building. First and foremost: It is more complex than it appears. This can lead to solutions that don’t work, schedules that overrun, and poor outcomes. The number of individuals who must coordinate over an extended duration also increases project complexity and removes resources from other areas. Organizations that build rather than buy also run the risk of reinventing the wheel by designing features that all vended solutions would provide out of the box and that therefore convey no competitive advantage. Most IT organizations are not designed as software engineering organizations; turning one into one would take time and investment that many carriers can ill afford to spare. Finally, the promise inherent in a build—a custom-made tool that will meet all requirements—often goes unfulfilled. It is rare to find a custom build that is competitive with market-leading vended solutions—and few carriers who have tried to build one would do so again.
Organizational Capabilities and Risk Mitigation
Carriers that are successful in custom building typically have engineering teams dedicated to the product build. Specialized engineers must often be hired with skillsets that differ from the rest of IT. Some carriers have even gone so far as to set up build teams in separate office spaces or as subsidiary companies to ensure the right “culture” can take root. Additionally, such teams require the experience with frameworks like SCRUM, Kanban, SAFe, LeSS, and FAST to be successful. They also need to deploy sound DevOps practices. Finally, successful organizations will have a track record of large, custom builds. Those that do not will require months or years to hit their stride—and may lose confidence in their approach by then.
The risks inherent in building software in-house can be partially mitigated by purchasing software components off the shelf and/or teaming up with a co-development partner. Carriers can avoid building some capabilities from scratch by leveraging off-the-shelf components through software libraries like Hibernate or platforms like Salesforce and PEGA. Off-the-shelf options also exist for things like rating, workflow and BPM, CRM, print, document, image storage, and digital capabilities. In addition, carriers can engage a software vendor or consulting company as a co-development partner. Performing due diligence on the partner and their engineering maturity is crucial.
Maturity in the competitive vendor market means that buy vs. build debates occur less often than they did 20 years ago, but they still happen surprisingly often. Building is rarely the easiest option and many carriers that do it underestimate the real costs and risks. For the limited cases where it may be appropriate, carriers can increase their chances of success by approaching core builds the way successful software vendors do.
Novarica’s recent brief, Insurance Core Systems: Buy or Build? provides more information on reasons for and against custom core builds as well as key capabilities that IT organizations need to ensure a successful build.