TAL Services, a wholly owned subsidiary of Dai-ichi Life Group, has been providing insurance services within Australia for many years, though it was not a well-known brand to the general community until last year.
The organisation has 1600 staff across six offices, but until 2016 the business primarily worked through financial advisers, through insurance bundled with superannuation funds, and via a white-labelled arm with products available through Qantas Assure.
TAL believes all Australians should be able to access life insurance and last year went to market with a public brand. This was a major launch, known internally as the TAL consumer launch, introducing direct-to-market products for consumers.
The launch was no small affair; the brand launched with television ads — like that below — as well as a new website, and a customer self-service portal.
The self-service portal did not exist previously, yet the advertising was all booked so the portal had a hard deadline by when it had to be created. This portal, MyTAL, was a key component of the launch and it was imperative it worked.
Richard Mountstephens, lead enterprise architecture, TAL, said the development was, for the most part, a greenfield development and he needed to design a site which offered useful information to TAL’s customers on the products they owned. The site must allow secure registration and login. TAL has four million customers, Mountstephens said, “and while not all are logging in on day one, the new application had to scale".
“A customer portal needs an identity capability,” Mountstephens said. His interest in identity-as-a-service had been piqued previously, having worked with on-premise identity solutions in the past elsewhere and knowing they could become complex.
“Another good thing was the usage-based pricing,” Mountstephens said, explaining that only a subset of users would log in on any specific day. “Life insurance is not like banking; people mostly log in to pay their premium or change their address, so they only do it a couple of times a year.”
For this same reason, TAL implemented a passwordless login feature. As users would only log in infrequently, it was anticipated they may forget their password. To alleviate this, Mountstephens and the TAL team built a one-time password capability so users could login with their email address, receive an email link, then click that to access the site. This was achieved using Okta’s fine-grained APIs, under orchestration of the TAL developers.
MyTAL successfully launched in August 2016. At that time, Mountstephens and the team worked around features not present in Okta, which have since been introduced. These include customisable screens to provide branding and redirection without having to program them yourself, and also vanity domain names and vanity email addresses. “As we develop new login experiences for new sites we will look at using more out-of-the-box Okta functionality,” Mountstephens said, adding that the new features would accelerate development for smaller companies without an in-house team.
Mountstephens’ used his architectural vision to flesh out an enterprise login identity through the MyTAL project. He explained TAL was now working on refreshing its Adviser portal, and previously refreshed a superannuation portal used by funds. In both cases the same Okta-based functionality for login has been re-used and continues to serve the organisation well.
“We started with our customer and channel partners, and now we are looking at staff,” he said. “Cloud is one of the use cases that is taking us there. Our developers use Jira and one of Okta’s strengths is its pre-built connectors, so now we have a footprint with Okta we are looking into this.”
Building the website with SiteCore was easy enough, Mountstephens says, but blending UX and identity with content experience brought some development challenges such as bringing Angular together with SiteCore.
The retail system had its 30th birthday last year and holds a lot of policies, but the TAL executives were in complete support of the architectural vision of building an enterprise API layer. “Often project pressures can lead to point-to-point solutions but we wanted APIs to build out an enterprise insurance claim flow,” Mountstephens said, “so as each project came out we built up our APIs, setting us up well for each ongoing portal.”
TAL continues to use its API pattern for internal and B2B applications under Mountstephens’ vision of a common API layer.
TAL also ensured it brought data standards into the game. “One of the big challenges in API design is handling data objects you bring back and forth, so coming up with a common object for all the business units can be challenging,” Mountstephens said.
TAL uses the Accord Standard, a general insurance model, so Mountstephens and his team used this as the starting point for their own enterprise data model.
“Standards are often the compliance that slow you down; we used it as a way of acceleration by not having to develop from scratch. Keeping it agile is an area of focus for us. I believe when developing APIs you want to be clear early on about your re-use strategy,” Mountstephens says.
TAL engaged Okta directly, enthusiastically describing their Okta sales contact as half-engineer, half-architect and half-sales.
“When customers come onto our site to check out quotes they can slice and dice and get different quotes and save them. Okta helped us with how to use their APIs to do that,” Mountstephens said.