Microservices are entering the “early adopter” phase in large, established corporates.  I was talking to a friend who works for a large systems integrator, and he told me that this is now a common topic of discussion with CIOs. His client is a large insurer, and they are migrating the back-office IT systems to a microservices architecture. Interestingly, they are also using this as a lever for organisational change, creating “pillars” around core business areas, rather than departmental “layers”. The entire IT infrastructure is being transformed, with containerization and API gateways as key enablers, and the solution architecture team is now focusing on time-to-market as a key driver – their previous focus was on standards compliance and long-term strategic fit.

It sounded like a very cool project – not just turning around a super tanker, but reconfiguring it to something fundamentally different. So, when I asked which new customer propositions the insurer would deliver, I was confused when my friend said “oh, that’s not really a priority”. The project is driven by IT, and their goal is to be more responsive to the needs of the business, but the microservices solution will not extend to the customer touchpoints – the website, the call centre applications, etc. When I asked why not, the answer was a little complicated, but I think it boiled down to “the teams responsible for those touchpoints had large, complex software packages which they were afraid to change”.

Microservices can have a dramatic effect on back-office solutions – but the true value comes from transforming the way businesses interact with their customers, by opening up new business opportunities or channels. Seeing it purely as a “back-office” solution just means you get better at delivering yesterday’s service, rather than opening up tomorrow’s opportunities.

Updated: