Admiral Group’s history is one of meteoric growth, and to ensure it maintains its trajectory the motor insurance provider is crafting a software development strategy that will enable it to nimbly respond to a fast-changing, competitive market.

The FTSE 100 company launched in 1993 from its South Wales base, with one brand and no customers. Today it has nine brands ­ – including household names such as Diamond for women drivers, and online insurance specialist Elephant.co.uk ­ – more than 1.5 million vehicles insured and 2,500 members of staff.

Continuing that success, says group IT director Steve Webster, relies on IT supporting the launch of new business ideas. “We want to be able to bring new products to market quicker than we can at present with our current IT system,” says Webster.

This devotion to supporting business enhancements has led to a root and branch review of Admiral’s software development process, aiming to establish an IT roadmap that maximises agility while minimising disruption.

The review was instigated after the launch of MultiCar, which focuses on insuring households with two or more cars. It took about six months to get up and running, but Webster believes IT should be able to support such initiatives in a fraction of the time.

“We launched MultiCar because the business needed to, but it took time to develop and we realised we needed to increase operational agility,” says Webster.

One of the roadblocks was the company’s ageing insurance system, Insure/90, bought in the company’s early days. “The technology was a market leader at the time. The package was sold with the source code so we could extend it with our own development team to look after it,” says Webster. The result is a bespoke system.

After 15 years of intense development, the software has become very “Admiralised”, says Webster ­ – and that has some unfortunate side effects. “It is not scalable or flexible and there is no agility surrounding development,” he says. “Developing a new product takes too long and it runs slowly. In two to three years’ time, we might be struggling if we don’t change because our main software platform won’t be able to support the business.”

Insure/90 also relies on an ageing programming language ­ – RPG, the mainstay of IBM’s iSeries platform.

Admiral identified two fundamental problems in its ability to quickly develop MultiCar. “The system’s database is old and large and it is difficult to make any changes to it without having a huge impact on the system which limits the speed of change. And the source code has been heavily customised over 15 years so it is highly integrated and the opposite of modular,” says Webster.

The need for a software team with RPG programming skills added to the desire to evolve the current system. “RPG programmers are hard to come by. There is no one learning RPG at university ­ – the choice is usually Java or .Net. So, there is a cost implication, as RPG programmers are experienced and relatively rare. We currently have the skills set, but it is not sustainable,” says Webster.

Such constraints are markedly at odds with the business environment. Admiral’s growth is fuelled by its ability to launch new brands. Added to this, the ways of interacting with customers are changing rapidly ­ – from a reliance on the telephone, business moved increasingly to the internet, with much of it now coming via specialist aggregator pages.

Knowing that a new course is necessary is one thing, but plotting the most effective strategy is something else. Admiral called in IT services company CGI to analyse its options.

“CGI understood our dynamic and informal culture and worked with us in a collaborative approach; their input will help us make the best decision. We have learned all the skills we need in order to make the best technology choice,” says Webster.

Admiral and CGI evaluated three basic options. Replacing the entire Insure/90 package was regarded as too “slow-burn” and risky. Updating legacy systems with new components was not possible, because of a lack of viable alternatives on the market. It was decided that a programme of extending and updating its legacy infrastructure provided the best chance of success.

“We decided on a course of technical innovation – ­ to build new functionality one piece at a time – ­ and presented this option to the board. It gave us the go-ahead in January 2008. The key business benefit is that it is low-cost, low-risk and we can always stop,” says Webster.

Admiral’s software team will create so-called data wrappers to encapsulate functionality that can be re-used by legacy systems. “It will allow us to build all the components we need and retire our legacy applications over the years,” says Webster.

Two teams of developers have investigated building data wrappers internally using either Java and the J2EE platform or Microsoft’s .Net.

Admiral already has a team of 30 software developers with Java skills, as the current front-end systems are written in Java.

“The debate about which is better ­ – Java or .Net ­ – rages on. I believe that Java is a more robust enterprise-level development tool than .Net, which is best used for rapid application development. Java is more flexible and has the open source community behind it,” says Webster.

An alternative to in-house development using Java or .Net is to buy business processing management re-engineering tools. This option would have a big impact on the software team’s role.

Packaged customer relationship management applications, such as Sword Ciboodle or Chordiant, can provide rich off-the-shelf functionality tailored for contact centre deployments. Deploying such tools would mean Admiral placing greater emphasis on “business analysts than programmers”, says Webster.

Admiral is undertaking a detailed assessment process before making a choice between internal development or buying tools. Webster says technology criteria include flexibility, ease of maintenance, speed of development and deployment, and scalability, while business criteria will focus on usability. Future-proofing the system is another imperative as well as cost.

“Five years ago, 10,000 quotes a day came via the aggregator channel. Now it is more than 200,000. There is pressure on the architecture and we need it to be scalable and secure as well as facilitating speed to market. Financial implications and the time it will take to realise benefits are also important,” he says.