In the last couple of weeks I’ve had the great opportunity to spend time with IT architects of various sorts both inside and outside of the insurance industry. The discussions have been illuminating and offer different visions and futures both for technology that supports insurers and for the future of the architecture function in insurers.
One of the main events that allowed for this conversation was a round table held in London with architects from insurers. The main topics were the relevance of microservices style architectures to insurance, the role of the architects in AI and InsurTech and the future role of architects at insurers. Another event that offered an interesting contrast was the inaugural London Software Architecture Conference which I'll call SACon below (Twitter feed).
I won't fully define microservices here but briefly it’s an approach to delivering software where each service is built as it’s own application which can be scaled independently from other services.
Microservices as a way of delivering software was the default approach at the SACon. There were sessions where architects sharing stories about why sometimes you had to work with a monolith or even making the case for not having the services in discrete applications. Meanwhile at the round table the monolith was the default still with the case being made for microservices in some parts of the architecture.
There are use cases where microservices make a great deal of sense, particularly in already distributed systems where a great deal of data is being streamed between applications. Here the infrastructure of microservices and the libraries supporting the reactive manifesto such as Hysterix and Rx* (e.g. RxJava) and indeed one insurer related their use of microservices to support IoT. Others discussed using this style of approach and the tooling surrounding these architectures to launch new products and increase change throughput but in all cases these were far from replacing the core architecture.
For now microservices is not the default for insurer software but is certainly a tool in the box. An observation or two from SACon from those looking to adopt: First it doesn’t solve the question of how big a service or a component is, something architects need to discuss and refine and; Second, microservices needs a great deal of automation to make work, a topic covered in our DevOps report to be published shortly.
Architects and AI
I have a background with training and experience both in computer science, AI and machine learning. One thing that I noticed going to the analytics conferences where AI is discussed is the absence of IT representation – plenty of actuaries, MI/BI folks, marketing folks – was this a place for architects?
Most insurers present at the round table had activity within the organisation for AI. For the most part only data architects are involved in this discussion – AI being distinct from business and applications architecture for now. It’s my opinion that AI components will form part of the wider applications architecture in the future, with AI components being as common place as programmed ones.
Architects and InsurTech
Here is an area where architects can more immediately contribute in a meaningful way both in reviewing opportunities and unique capabilities from InsurTech firms and in discussing integration where acquisition rather than investment is the goal.
The challenge here of course is the age old challenge for architects – to have a seat in the discussion the architect function needs to demonstrate the value it can bring and it’s internal expertise.
Finally, one amusing discussion I had was with a few architects from startups. As I discussed legacy systems they also related seeing legacy systems in their organisations – albeit the legacy systems were 2 or 4 years old rather than 20 or 40 years old. The intriguing thing here was the reasons for them becoming legacy were the same as insurers – availability of skills, supportability and responsiveness to changing demands. It may hearten architects at insurers that start ups aren’t immune to legacy issues!