Mitigating vendor lock-in risks

20-10-2014

Treefrog Consulting

Mitigating vendor lock-in risks

Choosing, implementing and running risk management software can be an expensive and frustrating task. This pressure can be eased by relying on experienced specialists who can help cut through the complexities and reduce costs, as Dmitry Mnushkin explains.

I had the pleasure of speaking with a new insurance-linked securities (ILS) entrant a few weeks ago. They were in the process of getting their back office set up and wanted to know what systems they needed to have in place in order to get the job done. When I told them that a reinsurer I knew had spent $20 million per year on its systems they laughed in disbelief.

In a world full of apps, tailored web offerings and endless desktop tools it is surprising and disappointing that a simple answer to my client’s question is still not available. There is no ILS-in-the-box you can purchase with everything required to conduct business.

Every choice quickly becomes a decision matrix. Do you want to build or buy? Do you want to do this in-house or outsource? Which parts of the business will be black box and which are non-differentiating? Have some of the systems already been supplied by a parent company? What are the regulatory requirements? What catastrophe modelling needs to take place and which vendors will be used?

Seek insights in experience

Relying on past experience is the best way to answer these questions meaningfully and with reasonable certainty. Although business models are constantly evolving, experience has allowed us certain insights into the software provisioning process that may seem obvious in hindsight but are easily overlooked in the heat of the moment.

The most important step for a business newly entering the market is to acknowledge that it does not yet know its full tool requirements. Without this detail it is premature to spend heavily on infrastructure and various software products.

Not every business model can afford to wait on a full system roll out. Those that can and are cost-conscious should buy the tools they know they need now and do the rest by hand. This approach has the double benefit of giving people intimate insight into the pain points and inefficiencies of the process while generating a wealth of valuable requirements based on actual need vs theory. 

“The first risk-mitigating step should be to select a vendor that has a long history of being reliable and reasonably priced.”

After a few months of doing things relatively manually, requirements will have been firmed up to the point where informed tool selection can take place. Now it is possible to evaluate various vendor offerings in the context of well-defined needs without being side tracked by pretty graphs and fancy reports. We all know the irresistible appeal of shiny things when presented by skilled salespeople. Having a document full of hard requirements will focus tool selection on business priority items.

The software selection process will uncover many competing products in each category. Selecting the most suitable tool must involve criteria such as ability to meet current and projected needs, price point, security considerations, etc.

Another aspect that should be considered is the ability of each tool to be programmatically controlled via application programming interfaces (APIs). Think of APIs as remote control ability for a piece of software. The more advanced the APIs supported the more aspects of software can be controlled by your own developers. This allows for third party tools to be fully integrated into the local software ecosystem, thus eliminating human intervention in the business process as data seamlessly flows from one tool to another.

Beware the lock-in

APIs also serve another purpose for software vendors. They provide one of the most effective methods to lock a customer in to their product. Vendor lock-in occurs when a company using a piece of software grows so reliant upon it that neither bad service nor price increases can convince it to switch to a competitor.

The best way to accomplish this is by having the customer tightly integrate the software into their environment, making it very costly and time-consuming to subsequently disengage. This trap has no easy way out. If tight integration is required to maximise efficiency and unlock potential, how can vendor lock-in be avoided?

The answer to this question is multi-pronged. The first risk-mitigating step should be to select a vendor that has a long history of being reliable and reasonably priced versus its competitors. The second is to integrate to the least level possible while achieving efficiency targets. The fewer the ties to a given piece of software, the easier it becomes to cut them in future.

The third approach is to identify critical, differentiating categories where replacing a closely tied vendor would be difficult but building the functionality that the vendor supplies in-house is possible. The main candidate category for this approach is the so-called black box solution that contains the corporate ‘secret sauce’. Developing this in-house carries an up-front cost but has a number of benefits beyond avoiding vendor lock-in. It allows the company to tout its technological prowess as a differentiating competitive advantage in the process justifying better ratings, displaying superior risk/portfolio management and commanding premium pricing.

Understanding your business process intimately permits thoughtful, right-size tool selection. Understanding the appeal and danger of vendor lock-in encourages the growth of business software ecosystems that are resilient, cost-effective and long-lived. Keeping corporate secret sauce in a custom-built black box is just plain good for business.

Dmitry Mnushkin is the president of Treefrog Consulting, a Bermuda-based consultancy specialising in custom risk portfolio management systems and tools for the reinsurance, cat bond and ILS space. He can be contacted at: dmnushkin@treefrogconsulting.com 

risk management software, Treefrog Consulting, APIs, cat models

Bermuda Re