Founded in 1810, The Hartford Financial Services Group is one of America’s oldest and largest financial institutions. From its origin in providing fire insurance to Connecticut businesses, it has become a leading provider of automobile, homeowners’ and business insurance. It also offers investment products such as annuities, mutual funds and college savings plans, as well as life insurance, group and employee benefits. Serving millions of customers around the world, The Hartford’s nearly 30,000 employees and $27.1 billion in revenue in 2005, place it as number 78 on the Fortune 100 list. About 11,000 independent agencies and more than 100,000 registered broker/dealers sell The Hartford’s trusted products.
In 2002, The Hartford began to explore the advantages of creating an enterprise-wide common reference architecture as a platform for business applications. At that point, according to Benjamin Moreland, the director of foundation services in the Office of Technology at The Hartford’s property-casualty division, the company’s applications were tightly siloed within each of its main lines of business. “Each developed its own applications with its own architects,” Moreland said. But, he noted, the company realized that “there were common business problems that could be solved across business lines. We needed to address that.”
Several of the division’s business segments, particularly its personal and small business lines of insurance, had common challenges. In both areas, for example, there was enough separate information to potentially leverage common solutions to manage the entire process from quoting rates to issuing insurance online.
A New Foundation
With that in mind, the company set about to establish an enterprise architecture.
The project had three primary business goals – lower the total cost of IT ownership; speed up the time it took to get products to market; and improve the ease of doing business. For example, although The Hartford provides insurance for most types of business in most places, from time to time it will change its criteria for coverage. The company wanted to be able to alert a broker about its interest in insuring a business before the broker completed the entire formal application process.
As the company explored its options, the architects realized that a service-oriented architecture (SOA), “was the only way that we could achieve our business goals,” Moreland said. “We never did SOA for the purpose of SOA.
And we never had to justify SOA to the business because we use it as a philosophy and tool within our enterprise architecture approach to meet our business needs.”
Moreland’s team was assembled in 2003 with a mandate to put the needed platforms and infrastructure in place. The first application to draw the team’s attention was the Single Entry Multiple Carrier Interface (SEMCI). Using the international ACORD XML standards for the insurance industry, SEMCI allows insurance agents to communicate and exchange data with multiple carriers for quoting, policy issues and inquiries. The Hartford had been on the forefront of the implementation of SEMCI.
The Hartford’s initial implementation of SEMCI had been as a tightly knit application. And, over the years, as the interface had evolved, the different components had become more tightly coupled. “Every time an enhancement was made, it became more difficult to do future enhancements because of the downstream effects,” Morehead observed. Moreover, The Hartford used SEMCI primarily for smaller customers. When the company investigated the possibility of re-working SEMCI to accommodate larger business customers as well, it found that the cost of rebuilding the application would be more than the cost of creating the infrastructure needed to move towards SOA.
Moving SEMCI to SOA
In assessing SEMCI from an SOA-perspective, Moreland and his team determined the application performed a handful of basic tasks. It authenticated agents. It validated the ACORD XML messages and standardized the values. It translated the XML into a format compatible with The Hartford mainframe – AL-3 and COBOL Copybook. It retrieved quotes from the mainframe and translated them back into XML. And it compared the incoming and return messages to note discrepancies.
Since each operation could be seen as a stateless service, Moreland felt the application could be efficiently refactored using an orchestration of services approach. Critical to the move was the use of a UDDI registry. “We created a simple Java orchestration service that determined what kind of ACORD message it was,” Moreland said. “It then called the registry to get the specific service interface required, called the Web services management (WSM) platform and the WSM platform would use this information to call the service.” For the company’s first enterprise SOA application, it used SOAP and WSDL. A management platform providing real-time performance monitoring was also implemented. “We had real-time feedback not only to see if we were meeting our customer SLAs but we also set up SLAs on each of the services. That had never been done before,” Moreland said.
Surprise Benefits
The move to SOA provided several anticipated and unanticipated benefits. “We started to have visibility into problems that we never knew existed,” Moreland said. For example, The Hartford’s mainframe computer routinely prioritized jobs, but from time to time an agent would not receive a quote because the mainframe was working on a larger batch job. After receiving a “timed out” message, the agent generally would resubmit the information and get a result. Nobody ever reported the glitch. “People thought we had introduced a problem but we had always had it,” Moreland said. “Now we were able to fix it.”
Secondly, the move to SOA has had a dramatic impact on maintenance. Under the old structure, if a large application experienced problems, it would be moved to an exceptions environment and a large team of experts would review debugging messages and logs to try to determine the source. Once the problem was corrected, extensive testing was required. “You might find downstream effects from the changes,” Moreland said.
With SOA, the source of the problem can be pinpointed more quickly. And because the services are stateless, there are no downstream effects from changes. Consequently, fixing problems “requires fewer people and less testing. There is a huge savings in terms of time and resources,” Moreland said.
Third, the move to SOA has provided the agility for which companies so often clamor. The Hartford is now using the SOA platform for twelve applications and one service in particular is being used by seven different applications. One of those applications required a faster response time for translation services than available previously through a combination of style sheets and software algorithms.
The company was using an XML accelerator for authentication services, Moreland observed, and the team decided to leverage it. “All we had to do was take the service interface and point it at the accelerator instead of the software-based transformation process,” he said. “We passed it the same style sheets as the software algorithm. Not a line of new code was written.” The response time dropped from three seconds to 12 milliseconds. Similarly, at one time during the implementation process, the company needed a .NET client to call a Java service. The estimate was that it would require three to five weeks to build a bridge. “Using our management platform and a SOAP-based approach, we did it in two hours,” Moreland said.
Development and Culture
At this point, Moreland’s group has developed around 150 enterprise services and the team continues to try to identify common functions that could be turned into services. For example, he noted, five business applications associated with five different lines of business require the use of motor vehicle reports (MVR). “We are developing a business case for making a common MVR service leveraged by those lines of business,” Moreland said. But creating a common service is not just a technical issue. Cultural and organizational factors are involved. People have to feel comfortable to use services that they do not “own,” Moreland noted. To that end, The Hartford defines “contracts” that include quality of service, availability and response times, as well as the interface that evokes the service. The idea is that application owners will only use services they know they can trust. Since Moreland’s team is responsible for the SOA infrastructure, including the rules engines, BPM, BPEL, orchestration, management, the portal and so on, it can also alert service owners if they are in danger of not meeting their SLAs. “The insight is essential. If you have multiple consumers, they may have different payloads,” Moreland said. The services can be analyzed according to a wide range of different variables.
Next Steps
SOA, Moreland cautioned, is not a “silver bullet.” Nonetheless, he sees it assuming an increasingly larger role at The Hartford. As functions on the mainframe become exposed as services, over time they can be migrated to other platforms. But the real issue isn’t replacing mainframe technology–which Moreland does not believe is going away–but determining what should be a service. “What are the criteria for an enterprise service?” he wondered. “What is the business plan? What are the rules and regulations?”
Over time, Moreland anticipates that business processes will be expressed as a dynamic aggregation of functions exposed as services. Reusing services will allow The Hartford to avoid having to take the risk of trying to implement massive IT projects. Moreover, SOA will help the company more fully understand the total cost of a business process and the total cost of changing a business process. Before, Moreland noted, only the cost of the complete application was measurable. With SOA, he said, the company will better understand the total cost of ownership along the entire lifecycle.
