The Hartford Builds An SOAThe Hartford Builds An SOA

Before The Hartford launched construction of its service-oriented architecture, the large insurance and financial services company sequestered 50 IT managers and 50 business managers and had them draw up a five-year plan for the company.

"We're a second-tier insurance company. That's not acceptable. What's it going to take to become a tier-one company?" was the central point of the meetings, said Benjamin Moreland, director of the company's office of technology and a leader of The Hartford's SOA implementation. Answering that question "became a big driver of the move to SOA."

But getting to SOA means a willingness "to break down organizational silos. You have to do it. You must align IT with the business and not just have lip service," Moreland told attendees of the Burton Group's Catalyst Conference in San Francisco earlier this month.

Moreland defines SOA simply as "a loosely coupled enterprise architecture based on industry standards, with technologies capable of using those standards." The Hartford started by adopting a set of standards: XML, Soap, and the Web Services Description Language. The list has since expanded to include Business Process Execution Language; Java Specification Process 168, which defines a way for Java commands known as portlets to function with any portal; and Web Services for Remote Portlets. By organizing around technologies that support these standards, The Hartford was able to start building services that were accessible to many different applications. "Think strategically, but act tactically. Start small," he said.

By building a key function--such as address verification or a Department of Motor Vehicles driver's license check--as a service, a business process can be changed or modified without altering many lines of code.

Getting results quickly is necessary to collect user feedback and keep the SOA process credible. Identify a pilot user group and deploy a new version of a service or set of services to it for feedback. If the pilot group says it doesn't work, "throw it away" and try again, Moreland advised.

The maintenance of central services costs less than maintaining an old application infrastructure. The code behind a business process is easier to isolate, understand, and revise when it's contained in a set of services than when it's buried in large, monolithic applications. Still, as the number of services mounts, it's important to add SOA governance to manage the service's life cycle and maintain it. If you don't have governance, the SOA is going to do what architectures before it have done: become a maintenance burden and eat up the IT budget, Moreland said.

Although The Hartford has a three-year start on its SOA implementation, Moreland said: "In this marathon, we're only at the two-mile marker" with another 24-plus miles to go.