This is the 4th post in a series featuring our customers that are driving business innovation through application development. It’s been great to hear the stories and share them with you.
Towers Watson is among the top global providers of consulting and technology solutions for insurance companies—especially in the areas of people, risk, and financial management. Over the decades, it’s brought a range of innovations to the industry, including new ways to analyze risk, price auto insurance, and evaluate capital requirements.
So, when insurers sought a way to implement what is proving to be the most disruptive innovation in today’s auto insurance market—usage-based insurance (UBI) pricing—it was no surprise that they would turn once again to Towers Watson. And maybe it is no surprise that Towers Watson turned to Microsoft Azure.
Leading the implementation drive for the new UBI solution is Andy Lingard, Global Leader of General Insurance Software Development for Towers Watson’s Risk Consulting and Software business. We spoke with him about the company’s solution, how Microsoft Azure supports it, and what advice he’d offer other corporate application teams.
What’s the business problem you were trying to solve for your insurance-industry customers?
Lingard: Virtually every company in the auto insurance market wants to get into usage-based insurance, UBI, because pricing policies based on how drivers actually drive enable companies to be more competitive and more profitable than companies whose policies are based on traditional criteria, such as the driver’s demographics and claims record. It can also be used as a way of improving driving standards and contribute to road safety.
That’s the opportunity. Here’s the challenge: Processing and analyzing highly granular data feeds from automobiles, and integrating that information with third-party feeds, make for a compute and data-intensive workload. For many smaller insurers, the capital and operating expenses to build and support such a technology infrastructure are daunting if not prohibitive. And then there’s the risk of overbuilding, and sitting on unused and unprofitable capacity, or underbuilding, and being unable to meet demand. We wanted to provide our customers with a UBI service that they could adopt without incurring these risks.
Why did you choose Azure?
Lingard: We’ve had a major evolution over the past few years in how we support big computing workloads at Towers Watson, and Microsoft plays a growing role in that support. We’ve moved a number of strategic large-scale compute solutions from on-premises implementations to hybrid deployments with the cloud, and we find Azure increasingly useful to us and our customers. For UBI, we first prototyped a solution three years ago, and we’ve been working with customers on pilots and full production systems since then. When we thought about preparing for millions of vehicles, the expense needed to process the advanced analytics in our solution was extraordinarily high. That’s where Azure comes in. We use it as part of a hybrid solution: an on-prem data warehouse supports an off-line R&D environment used to continuously evolve and improve the analytics running in the system; the bulk of the data, including all trip and sensor information and third-party feeds, is stored in the cloud. The analysis happens in the cloud, and scores and reports are returned to an on-prem reporting application.
We had choices about a cloud provider, of course, but our customers have standardized on the Microsoft technology stack and so have we. That makes Azure our go-to choice for the cloud.
What do you think is working best?
Lingard: We need to do UBI better than anyone else and more cost-effectively than anyone else, and Azure is crucial to our doing both. On the “better” side, we actually monitor vehicle telematics data, such as position, speed, and acceleration, for every second of every journey of every vehicle. We integrate granular environmental data to provide a context from which to compute driving behavior and risk assessments. And we run analytics that are more sophisticated—and more predictive—than those of competitors, which make them more valuable to insurers. We use Azure to do this quickly and reliably. On the “cost effective” side, we estimate Azure saved us 20 percent in initial capital costs compared to building a datacenter solution. And we forecast saving between 30 and 40 percent in capital and operating costs as the number of vehicles scored by the solution develops into the millions. That cost-saving is helping us to bring advanced UBI within reach of many insurers who couldn’t afford to build it on their own or choose not to invest in the required infrastructure. That’s huge for expanding the market—and our share of it.
A project like this requires close alignment with the business on app priorities—how do you achieve that?
Lingard: Multidisciplinary teams are essential. We make sure that our business, process, and architecture experts are always in close contact. Each of our major product suites has a global product leader who sets business direction. Working with that product leader is one or more technical product leads. The tech leads have deep business domain knowledge and work closely with our customers, both users and IT departments, and with our architects to ensure our products deliver innovative and effective insurance analytics solutions. These tech leads are co-located with our development teams, and work with them in an Agile/scrum fashion.
With this structure, the development teams get insight into both high-level direction and customer needs through the tech leads, and the developers and tech leads agree on goals on a sprint-by-sprint basis. We’ve found this to be an effective way to deliver software that our actuarial users—both inside and outside the company—will find most valuable. I’d recommend this approach to any company seeking close alignment between the business and tech sides of the enterprise.
Any other advice to business and technology leaders?
Lingard: When you’re building stuff that no one else has built before—which is the position we’re often in—it’s important to identify business and technical risks and unknowns early. Not every idea will work out. Where there is uncertainty, we use rapid prototyping and assessment to prove an approach, or fail early, when it’s fastest and cheapest to get back onto the right track.
One thing we have learned is the importance of creating a culture where it’s OK for some ideas to fail, as long as this does not happen all the time. Otherwise, it kills creative thinking.
See more cases studies about driving innovation with apps: www.microsoft.com/app-development
NEXT BLOG POST IN THIS SERIES WILL FEATURE DOCUSIGN ON FEBRUARY 12th.