SOA Adopters Discuss Best Practices
Thankfully, there aren't too many instances in which an insurance IT concept and quantum physics intersect. But if you mull over the defining principles of service-oriented architecture (SOA) long enough, the Heisenberg Uncertainty Principle may come to mind: As you attempt to define SOA in increasingly precise terms, the less accurate your overall understanding of the concept will become.
That's because SOA has no exact definition. Rather, it is an abstract concept. As a result, no vendor can offer an all-encompassing, out-of-the-box SOA solution.
"SOA is not a product," explains Stephen Kessler, vice president of application development at MetLife (New York, $481.2 billion in assets). "It's how you build out your systems."
In the traditionally risk-averse world of insurance, SOA's lack of concrete borders -- and thus measurable business value -- can be especially problematic. Embracing an SOA paradigm requires a leap of faith. A certain amount of trust is required on the part of the executive team that, while SOA investments in and of themselves won't directly deliver returns, the resulting application reusability and interoperability will.
"Is the business value in building the service-oriented architecture? No," Kessler says. But, "Do you need the service-oriented architecture as a component of the environment in order to deliver those high-value functions? Yes."
"Overall, the role of technology is to support your business needs," adds B.A. Scott, assistant vice president, enterprise architecture and engineering group, New York Life (New York, $225 billion in assets). "An SOA paradigm gives the system that you're implementing a lot more agility and flexibility to provide solutions for the business."
Industry IT executives, analysts and vendors all have different opinions on just how pervasive SOA has become in insurance. But just about all of them agree that it's among the most common discussion points in the marketplace.
Mark Gorman, strategic research adviser, insurance practice, TowerGroup, recently authored a report for the Needham, Mass.-based research and advisory firm on SOA. His research included interviews with 30 vendors. "All of the vendors that we spoke to said it was almost impossible to answer an RFP today without addressing service-oriented architecture," he relates.
SOA Best Practices
Despite the lack of clear guidelines defining SOA, enough companies have embraced it that best practices and lessons learned are emerging. The big-bang, all-at-once approach to SOA implementation has been largely ineffective, according to experts. Instead, the insurers that are seeing the most encouraging returns on their SOA efforts are those that took an incremental approach -- they started in areas that made good business sense and were able to communicate those business values to other parts of the enterprise.
"The most advanced SOA users started small and have just consistently devoted resources toward increasing their reliance on that model," according to Matthew Josefowicz, managing director, global insurance group, Celent (Boston). Josefowicz also has done his fair share of research on the topic, including the recent report, "Web Services and SOA in Insurance 2007: Realizing and Communicating the Business Value," in which he lists IBM's (Armonk, N.Y.) WebSphere, BEA's (San Jose, Calif.) Weblogic, J Boss (Atlanta), Apache's (Forest Hill, Md.) Tomcat and Microsoft's (Redmond, Wash.) BizTalk as the application servers most commonly used to support Web services and SOA.
Although SOA is a "think big" concept that can be leveraged across different parts of the enterprise, it's important to start small during implementation, confirms John Burke, vice president of insurance solutions for SAP (Walldorf, Germany). "SOA, in and of itself, is an enabling technology; it's an architecture that improves processes, both internal and external," he says. "There are so many systems inside of carriers and so many permutations that it can quickly get overly complex. So pick a business process that's meaningful to your business -- a line of business, a market segment. Pick something that is tangible and carve that out."
MetLife's Kessler, who is responsible for architecture and common components for the carrier's individual lines, says that some "textbook" SOA evangelists will suggest that a methodical architectural assessment of an organization's environment -- a list of services you have and services you need, etc. -- is the de facto starting point for SOA implementation. But, he asserts, that isn't the way things work in reality.
SOA: 'A Way of Life'
"In the real world, the business value comes from the business solution that we provide to the business," says Kessler, who began building out an SOA infrastructure at MetLife in 1999. "We started out building the services for what people needed, and we built out the infrastructure based on the needs of those systems. Then, over time, it starts becoming a way of life."
MetLife's approach to building out an SOA infrastructure shares some similarities with the snowball metaphor Microsoft sometimes uses to describe a recommended way to implement an SOA paradigm -- again, the idea being to start small. As the snowball picks up momentum, it grows bigger.
"The notion of starting with a specific business requirement and taking an experimental and experiential point of view on the whole process is definitely a good approach," says Dan Woodman, industry technology strategist for Microsoft's financial services team. "SOA is not something you can just take on and say, 'We're going to implement SOA.'"
But taking an incremental approach requires patience, notes MetLife's Kessler. "The early wins might not be as cost-effective as what you get in the end," he says. "You turn a corner at some point where you have critical mass and you have connections to most of the things that you need connections to. Now you are reusing all of that, and you are building up your infrastructure and your capability around a number of transactions that you can process through the fabric of all this. Now things start getting really cost-effective."
A lot of companies, Celent's Josefowicz says, stumble when it comes to staying focused on real, tangible business goals. Further, it's important to start slow, as a way to capture and document those delivered business values, he suggests. "This is something a lot of companies do not do effectively -- showing why they're making this investment," Josefowicz asserts. "It's not just because this is new technology, but because it's actually delivering business value by lowering project costs."
In Good Hands With SOA
Even when it is starting small, though, a carrier as large as Allstate (Northbrook, Ill.; $157.5 billion in assets) always has to think big. "This company has been strong in architecture for many years because of our size," says Anthony Abbattista, vice president of enterprise technology strategy and planning at Allstate. "We've had to think about architecture because of our scale and how we break a large task into smaller pieces. So service-oriented architecture was a natural extension of what I think Allstate has been doing for 20 or 30 years."
Abbattista describes Allstate as an early adopter of the SOA paradigm within insurance, although he notes that other financial services verticals were quicker to embrace SOA. Allstate, he says, has been evolving its efforts in Web services for the past four to five years to embrace more enterprisewide SOA concepts. "We see service-oriented architecture, done right, as a way to gain competitive advantage and to provide better services and experiences to our agents and customers," Abbattista says.
Allstate's IT department focused first on individual domains, some of which boast their own eight- and nine- figure IT budgets, and chose platforms and technologies that were most appropriate for each, according to Abbattista. Two and a half years ago, for instance, the company revamped its claims processes. In this particular space, it made sense to use .NET protocols to expose services and create a type of building block architecture for claims, Abbattista says. Meanwhile, Allstate's premium domain is mostly Java-centric.
"Where it got interesting was in cross-domain or interdomain," Abbattista says. "That's where we started to focus, from an enterprise level, on what services and functions we needed to expose. For example, what claims functions were important to agents or customers?"
That was easier said than done. Interoperability among Microsoft, Java and other platforms still requires a bit of work and architecture, Abbattista acknowledges. In the end, Allstate leveraged enterprise service bus concepts, from a third-party vendor, to bring together those interdomain enterprise services, he relates. "We put a lot of focus on how we build those out to be available, regardless of vendor platform, regardless of what went on in each of those domains, while liberating capital for new projects," Abbattista says.
"Those silos are coming down now because if you look fundamentally at an enterprise service, most of that is common components and common process steps," adds SAP's Burke. "There are lessons learned in repeatability across the enterprise, so good companies are breaking down those silos and behaviors and doing it from the top down. It's more than just technology; it's driving the business to be more efficient and better."
Tweet This