Building a long-term IT architecture

Sticking to a vision has its rewards. For AXA Financial Services LLC, those rewards add up to about US$55 million, which is what IT executives figure they've saved by adhering to a blueprint for the services-based computing architecture the company first laid out in 1990.

Over the past 13 years, the technologies have changed, but the central vision of a scalable, future-proof IT architecture based on reusing a core set of software-based services has stayed intact. The payoff has come from the ability to quickly and cost-efficiently develop, deploy and manage new applications across myriad customer channels, which the $480 billion insurer says gives it an edge in an industry better known for its IT conservatism.

The business driver for the architectural blueprint is the same today as it was more than a decade ago, says AXA Chief Technology Officer Don Buskard, one of the drafters of the blueprint. "Anything we do and have to redo is a negative-ROI project because we're just duplicating something we already did and spending money to do it without adding much value," he says.

Common Services

The three key reusable services the AXA IT architecture provides to all applications are common data access, data translation and security. These were initially developed by internal software developers who created proprietary code. Over time, however, as new technologies have become available from commercial IT vendors, AXA has adopted a strategy of swapping out homegrown programs for off-the-shelf software. But the company remains true to its original IT blueprint for reusable services.

The benefits of migrating to off-the-shelf products include greater flexibility and lower software maintenance costs, says Marvin Rafe, group director and chief architect. Rafe has been with New York-based AXA for 14 years and, like Buskard, worked on the original architecture plan. "Over time, the services requirements really haven't changed that much, but the technology underneath the services has changed," Rafe says. "We've had to change the technology underneath three or four times."

AXA started with mainframe technology, then moved to client/server and is now Web-based. Originally, AXA used IBM's SNA to provide communications and common data access to front-end systems directly from the mainframe. In the second phase, it eliminated direct connections between workstations and the mainframe. It also switched from IBM's OS/2 operating system to Windows on its servers and front-end PCs. In the third phase, object-oriented interfaces based on CORBA and TCP/IP technology for communications were key.

Most recently, AXA brought in Microsoft Metadirectory Services to synchronize all of its other directories and migrated from CORBA to J2EE (see timeline below).

AXA IT executives say that in each transition, the mainframe legacy transactions, customer data and agent data, which together represent the biggest investment, have been carried forward. "This services architecture allows us to retain and continue to leverage that investment while the underlying technology over which we really have no control continues to change," Rafe says.

For example, Rafe notes that the need for a service to aggregate customer data across multiple accounts residing on one or more of AXA's eight major computer systems remains the same, regardless of whether an agent is requesting it via a voice-response unit or the Web.

AXA's eight major systems include those that it uses for retail and wholesale distribution, sales applications, life annuity services, broker/dealer systems, applications used by AXA's financial services planning group and client-facing applications for customer inquiries and self-service via the Web.

"What we've done is separate the business intelligence and intellectual capital, which is the customer data, agent data and the ability to perform the transaction from the technology," says Rafe. That way, AXA can take advantage of new and better technologies as they emerge, without interrupting the delivery of key services, he notes.

A major infrastructure upgrade completed in 2003 from AXA's legacy CORBA environment to IBM's WebSphere MQ message-based technology serves as a prime example. AXA wanted a single software product to deliver a common way for applications to access data in back-end systems, Buskard explains. This approach even better streamlines the integration of new applications. It also enables new services, such as allowing users to perform a full complement of financial inquiries and transactions via the Web.

AXA chose WebSphere MQ, Buskard says, because it was already using IBM operating system software and was familiar with the product's predecessor, the MQSeries middleware.

The implementation wasn't a slam-dunk operation, however. IBM's initial WebSphere MQ software proved to be difficult for AXA developers to use, which slowed AXA's time to market with new services, says Buskard.

"Although (WebSphere) was a very robust transport that connected all of our systems, there was a fairly complex syntax. There was a large set of transactions with lots of parameters and lots of error messages to contend with," explains Rafe.

So AXA brought in Candle Corp.'s PathWAI application infrastructure management software, which Rafe describes as a software "wrapper" that masks the complexity of WebSphere. The Candle software manages the messaging services that need to take place among different AXA applications outside of the applications themselves.

An advantage of this approach is that "it's a simpler form of managing the underlying plumbing so that developers aren't forced to become familiar with it," says Dave Caddis, vice president of application infrastructure management at El Segundo, Calif.-based Candle. "It also makes it much easier for the development community to deliver a faster return on investment."

Integrating Siebel

AXA's new Web portal is another example of how the company was able to quickly incorporate existing services into a new application. The portal, which serves the sales staff, integrates AXA's e-business services with Siebel Systems Inc.'s CRM software and AXA's services-based architecture. The system combines Siebel's sales, marketing, call center and analytical products with Sun Microsystems Inc.'s Sun ONE Portal Server. The project took a year to complete and is now being piloted by about 100 beta testers.

"The value to our sales advisers has been huge, because they have to have a current picture of customer relationships," says Dave Wollin, AXA's group director of e-business. "Advisers now log into the portal in excess of 40 times a month. When they started, it was 15 or 16 times a month, but now it's multiple times a day."

Rafe says that one of the primary reasons AXA was able to complete such a huge project in a comparatively short period of time was its ability to take architecture-based services such as the ability to aggregate customer data across multiple accounts and plug that capability into the Siebel system, rather than create it again from scratch each time a new application is added.

"A lot of the same services (Wollin) is using on the Internet for e-business are services we built 13 years ago for the PC," Rafe says. "The services layer hasn't changed that much, because what the customer wants to see hasn't changed. It's the technology that connects in over time that changes, and because we've separated the services level from the technology, we have a lot of flexibility to make those changes."

Developing and then actually adhering to an IT architecture centered on software reuse is something that few IT organizations have been able to accomplish, especially over a period of more than 10 years, says John Rymer, an analyst at Forrester Research Inc.

"It's pretty unusual," Rymer says. It's also highly cost-effective, given the soft savings associated with software reuse, he adds. "You don't have to retrain developers on new interfaces, and oftentimes you see higher quality. If you've developed services over 10 years, it's pretty stable code, so you can improve your performance over the years," Rymer notes.

The bottom line is that AXA has saved a lot of money, says CIO Bill Levine. "We spent about $35 million on our architecture, and we estimate it would have cost us about $90 million to do the same thing had we not had an architecture in place," Levine says.

Reuse also guarantees efficiency and minimizes risk, he says. "In terms of our ability to execute, we're not fragmented," Levine says. "We can move developers from project to project, and they're not only familiar with the tools used for development, but with the services coming out of it. The only real variable we have most of the time are the new interfaces and the application itself. We're not always dealing with unproven services."

Snapshot

• Objective: Minimize development costs and ensure quality by designing an IT architecture based on a core set of reusable services.
• Challenges: Developing the services internally. Later, as AXA phased out proprietary code, the issue became choosing the right commercial products to replace its homegrown programs.
• Payoff: The ability to quickly and cost-efficiently develop, deploy and manage new applications across customer channels has saved the company some $55 million in development costs.
• Advice: Have a blueprint of your IT architecture and stick to it. "It's a management issue," says AXA CIO Bill Levine. "You don't let developers go around it."

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark