James Boother

10 May 2021

The technology challenge of mergers and acquisitions in the insurance sector

Mergers and acquisitions are going on all over the market at the moment … and de-mergers as well, actually. Typically in a merger or acquisition, there’s some knowledge that it’s going to happen in advance. But until the Heads of Terms have been signed and there’s a Transition Service Agreement in place, people don’t really get moving with the activity needed to support the move, particularly on the technology side.

This can be a problem, particularly for the acquiring party which is looking to get some benefit from the purchase. They want a return on the investment they’ve made and a lot of that value is in the intellectual property and the data that’s been acquired.

It’s really important that both sides at the point of the acquisition do some portfolio planning of the applications and technology platforms in use, and create some synergy between the different capabilities that are coming together. Understanding how the future organization is going to behave and operate and then looking at how the technology and data platforms can support the organization’s new objectives, are vital in making this new relationship work as expected.

For instance, what will the application portfolio look like in the future? There will definitely be some applications on each side that stay in use and some that are retired and replaced with applications from the other party, and that will probably be done on a case-by-case basis.

Let’s take the example of a big, established insurer that has bought a startup with a great consumer brand. The startup has a product that is very innovative and advanced, providing services that its customers love, which is why it’s grown to the size where it’s now challenging the traditional players.

You don’t want to lose that by taking the product and dropping it into the application the big insurer already has. What you might want to do is get more customers from your portfolio over onto this new product that everyone loves. Understanding exactly what the future outlook looks like for those applications is key. Then you can plan what the data requirements are, as well as the technology needs underneath them, and create a roadmap for the future to help facilitate what the business is trying to achieve.

Although mergers and acquisitions can be an excellent way to leap beyond organic growth, they have to be done in a controlled, realistic way that predicts how the teams and technologies involved will be integrated together.

Standardization is key

That’s not just about standardizing systems, it’s about standardizing approaches too. One thing that is really hard to integrate across and within teams is working practices, processes, tooling and even the format you use for your T-SQL code.

For example, I used to work with someone who was exceptionally clever. She knew everything she wanted to write when coding and she could envisage her T-SQL code just in her mind. As a result, the easy bit was writing it down and it would all end up on one line in the SQL files. Just one line, including nested queries, the whole shebang.

It sounds great, but the problem is that it’s actually a form of technical debt because it’s hard to decode what’s going on. The computer can read that one line of T-SQL easily, but what about the developer who comes to fix a production problem in a heat of panic three, maybe five years later? Can they interpret that one line of code as well as my highly intelligent co-worker did when she wrote it?

When it comes down to making sure systems can be integrated, we also need to figure out how the different teams should be integrated into one and their working practices standardized.

Team cultures also come into the picture

Part of team mentality is creating a culture and when you merge two organizations together, they will naturally have different cultures, even if they’re closely aligned. One team may be more accustomed to a DevOps style of working, automating where possible and releasing small changes frequently, while the other may have a more silo-based approach.

Whatever the differences are, they need to be resolved so it’s a good idea to look at where the best practice sits across the teams and maybe set up a center of excellence for the whole of the department.

Representatives from the different teams and any siloed sub teams should be included, because you want to have a fair and open voice from everyone. As soon as an individual or a team feel disenfranchised, they’re not going to take part in this innovation and process improvement you’re trying to achieve.

If you can make sure everyone has a voice and that you take an open approach to looking for where the best practice is and then role modelling that across all the other teams, you can reach a higher level of excellence across the whole business.

It’s enhanced by tools and processes

Once everyone knows how they’re supposed to be working, you can start introducing the best practices you’ve agreed on. Code analysis and good, solid code formatting standards will help, as will getting database changes under source control and having an auditable history of those changes.

Adopting these measures will start to break down silos, barriers and individual working practices, and having consistent, repeatable processes and tooling in place will result in a team-based development environment that works for everyone. Ultimately, you want to be stronger, with a bigger, more experienced team from the two organizations that have become one as part of that merger.

That also means you’ve now got this much bigger resource pool across the whole of your business and you can use the experts from all over the business to then come together and create further innovation.

By using the same tooling and following the same processes, and working with identical standards and conventions, they can come together and collaborate very quickly and get some great work done. That’s the point when mergers really succeed from a technology perspective.

You can find out more about how the database can be included in database DevOps by visiting our solution pages.

James Boother is the Sales and Marketing Director at Coeo, a Microsoft Gold Partner that partners with companies to predict their future through the effective use of data. Their Microsoft data platform and analytics specialists have vast experience of working with clients across their entire data journey – from modernization and migration to artificial intelligence and beyond.