The Hartford: Lessons From 3 Years Of Work On SOAThe Hartford: Lessons From 3 Years Of Work On SOA

Before The Hartford launched construction of its services-oriented architecture, the large insurance and financial services company took 50 IT managers and 50 business managers aside and sequestered them to 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 1 company," was the central point of the meetings, recounted Benjamin Moreland, director of the 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 June 15 in San Francisco.

Prior to such agreement on business goals, "IT complained that it didn't have a business road map that goes out more than a year," Moreland recalled.

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 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. Look for the low hanging fruit. Don't boil the ocean," 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 going into a large application and 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," he advised. The trial-and-error process works better than spending a lot of time trying to model business processes in a manner that suits everyone.

Services have become so popular at The Hartford that Moreland finds himself going into meetings and saying, "No, I don't want that as a service." Not every application function cuts across the organization in a way that can be reused many times. If it fits a single application, leave it as part of that set of code, he said.

But the maintenance of central services costs less than maintaining the old application infrastructure. The code behind a business process is easier to isolate, understand, and revise when its isolated in a set of services than when its buried in large, monolithic applications. As the number of services begins to mount, it's important to add SOA governance—a way to manage the service's lifecycle and maintain it. For example, does it have longevity or should it get phased out after a certain business period? Who can go in and change the code? How will such changes be tracked? If you don't have governance, the SOA architecture is going to do what architectures before it have done, become a maintenance burden and eat up the IT budget, he said.

"The organization is going to have to change. You're moving away from monolithic applications to centralized services—and the budget to maintain them," Morland said, leaving more resources for new code to be written and new services created.

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