Like many burgeoning tech start-ups, Australian insurtech BizCover, built a simple transaction platform in 2008 to cope with the initial flood of new customers and products.
But as the company grew and the suite of new products and services became progressively more complex, the tech leadership team at the highly acclaimed business knew it was time to upgrade.
Enter Blaze. The project developed in-house by the BizCover team to replace the current platform using the latest technology.
“After eighteen months using a small core team, we unveiled Blaze this year,” says Justin Goldberg, BizCover’s Head of Engineering.
“There were clear goals we wanted to accomplish with it, namely the ability to quickly add new products with more flexibility than currently possible, be able to deliver features whenever required without having a system outage, reduce the cost of change, improve our customer experience and attract the best talent in the market.”
And it’s worked a treat.
“BizCover, is the leading contestable business insurance platform in Australia and globally with a similar offering in the US, New Zealand and South Africa,” says Justin.
“We also provide white labelling for other comparison sites, and a broker platform which is more on the intermediated market, so things are changing on our platform all the time.”
Justin says his team can deliver changes on Blaze very quickly to production multiple times a day instead of every two weeks with the current platform.
“It’s vastly improved our customer experience and at the same time has made onboarding new products and partners a lot easier.”
Monolith or microservice?
While it’s all well and good to say that the new Blaze platform is markedly better than its predecessor, you will need to explore the world of software engineering to explain why.
A lot of it depends on the type of architecture that is used to build the platform. And most of the industry talk centres around when growing businesses should transition from their monolith to a microservice architecture.
Monolithic platforms were the default for creating a platform for well over two to three decades.
They are built as a single, indivisible unit that usually comprises a user interface, server application and a database stacked on top of each other. This makes it easy to initially build, deploy, and test since you can debug all of the different components simultaneously.
However, monolithic architecture has difficulty scaling up and incorporating new products and features that become more complex as a business grows.
“Monoliths are okay for a start-up that doesn’t know the domain, and they are still figuring things out. It makes things simpler when you begin,” says Justin. “A microservice architecture is more beneficial when you understand the domain better, and you’ve got an idea of what to build.”
Still with me? Well, think of it this way.
Imagine you are in a 20-story apartment building, and you need to change the plumbing on the top floor. With monolithic architecture, you would have to strip out and reconfigure the plumbing in levels 1 to 19 because they are all a part of one complex system.
And if you wanted to redecorate your penthouse, you would have to go up and down the lift 100 times, lugging materials back and forth, which takes way too long.
So instead, Blaze uses a microservice architecture.
“So with Blaze, what we did was that instead of building just one big apartment block, we’ve got a small little house that focuses on one thing, and we’ve got a suburb with many houses that each do something different,” says Justin.
If you want to change the plumbing in one of the houses, you just drive up to it. And the best part is that you can fix the plumbing in one house without it affecting the whole Blaze suburb.
“Essentially, each house or microservice is a fit-for-purpose system that just does one thing and does it well, whereas the apartment building or monolith is everything tangled together in one block.”
Moving forward in thin slices
While Justin and his team launched Blaze in May last year, the microservice platform is still very much in development.
“Each microservice component adds a new part to our overall platform. But instead of waiting for all the pieces to be compiled into one finished product, we’ve implemented what is called the ‘Thin Slice’ approach,” says Justin.
The Thin Slice concept in software development refers to implementing the simplest possible usable slice of functionality.
“This enables us to ensure the structure of the platform is up-and-running and usable before we add more complex microservice houses to our suburb.”
While Justin’s team has developed Blaze to consider multiple tenants and regions, the project’s initial scope only includes the ability to buy Professional Indemnity and Public Liability insurance for a set of occupations and pay either monthly or yearly.
“A customer can now cancel a policy and we will soon release functionality to amend a policy. We are also adding different question types that will allow us to add more products and occupations onto the platform and transition customers over to Blaze from the current platform,” says Justin.
“Rome wasn’t built in a day, and neither is a modern platform for a growing business. There will always be things in our platform to improve upon, but luckily at BizCover, we have an incredibly talented team with the full support of the executive team to make this happen.”
