Service-oriented architecture (SOA) is seen as a beacon of hope for insurance companies long beleaguered by tangles of incompatible legacy systems and networks. However, while the technology is now widely available, selling SOA to the business can be an uphill climb. Line-of-business executives outside the orbit of IT may not fully see or grasp the benefits of SOA.
The challenge for SOA proponents is to be able to demonstrate how the architecture can tackle even the most vexing business problems, and provide a return to the business in places where it counts most.
SOA has been known to generate new services, such as Web services that are tied to specific systems. But SOA needs to be sustainable over the long haul, with proven, repeatable processes that can be applied to any business requirement.
“The key to success in SOA is not the number of services that you have; it’s how often your services are shared,” Gerald Shields, CIO of AFLAC, Columbus, Ga., explains.
Such has been the experience across many successful industry SOA projects in which the results are strongly linked to the business.
“Insurers are discovering that the SOA approach is not just about Web services—it also creates the business and technology benefits of agility and flexibility,” says Scott Mampre, insurance practice leader for the Financial Services Strategic Business Unit of Capgemini, Paris.
At AFLAC, for example, SOA-based services are enabling the company to get to market quicker with new offerings, such as the company’s new Web-based self-service system. “We built that much quicker due to previous work that was done in 2006 and 2005,” Shields says. “For our new system offering policyholder self-service functionality, 30% of that code had been laid in services that we simply reused.”
Chicago-based Kemper Auto and Home Insurance uses SOA to modernize the company’s network of legacy systems, avoiding the need to take systems offline for months at a time and disrupt business. “The vast majority of our systems were developed in the late 70s and early 80s,” explains CIO Keith Sievers. “Our SOA strategy is basically directed at replacing those systems. Some are candidates for forklift replacements with packages; some are candidates for SOA replacement.”
By using an enterprise service bus from Bedford, Mass.-based Progress Software Corp., Kemper can update its systems on an incremental basis rather than taking them offline for one to two years for forklift replacements.
ELUSIVE BUSINESS METRICS
One of the reasons SOA has been a tough sell to the business is that SOA proponents have been hard-pressed to demonstrate tangible returns to the business. The returns to technology operations are easier to document. For example, Shields says, parts of AFLAC’s claims system are being rewritten and deployed as services. Such benefits may not become immediately apparent to the business, but will begin delivering over the long run.
“Our claims system—a ‘fat-client’ application—was put in several years ago,” Shields explains. “What value is there to go back and rewriting it? Is the claims system itself going to work any faster, any better? Is the average claims handler going to see any difference, because they put these as services? You could argue ‘no.’ But we’re an insurance company, and we’re going to be paying claims forever. SOA is an investment to make legacy code more agile and more responsive. And by having these services, we can share these services with online apps, such as self-service.”
Kemper’s Sievers agrees that direct return on investment to the business is difficult to measure with SOA projects, noting that SOA’s benefits are still seen “more at a philosophical level than at a financial level. It’s very hard to figure out your ROI on SOA—the true net cost of SOA.” For example, he says, SOA may require more time up front to build a new application, but cut down the time spent building follow-up applications. The time it takes to build the next application may be faster with SOA components, Sievers says. “However, it’s difficult to go through and try to figure out what your ROI is on each of your services.”
ENTER ITIL
Many industry advocates say that an emerging set of best practices, the information technology infrastructure library (ITIL), may be a key step to embedding service orientation into business processes through effective governance and management of SOA efforts. “The responsiveness to environmental conditions requires monitoring, reporting and responding—the key focus of ITIL,” Capgemini’s Mampre says.
ITIL is a set of best practices and is offered as a series of books sponsored by the United Kingdom’s Office of Government Commerce. ITIL has seen widespread adoption in Europe, and is now catching on in North America. ITIL is intended to standardize the way IT services are delivered to organizations across the globe, through continuous improvement. By adopting ITIL processes—service delivery, incident management, problem management, configuration management, change management and release management best practices—enterprises may be able to validate that their best practices are in synch with, and transparent to, the rest of the industry.
Version 3 of ITIL, released in June 2007, has elements that many analysts say will bring its services focus more in line with emerging SOA requirements. For starters, Version 3 focuses on the management of IT services across the enterprise as opposed to IT silos, explains Michael Tainter, IT service management practice director at Forsythe Solutions Group, Skokie, Ill. Service development teams will be able to work on leveraging and producing an agile IT when reusing specific services and applications from existing systems. “There are processes within ITIL called service level management, service portfolio management and service catalog management that help you define those requirements,” he says.
This support for service management makes it particularly valuable for architects and developers working on SOA projects, says Brian Statkevicus, SOA practice leader for San Francisco-based Primitive Logic. “ITIL V3 specifically provides for service strategy, which covers SOA planning and governance, as well as service design, which addresses service granularity and invocation standards,” he says. “Then there’s service transition, which covers change, release and deployment management organization roles, and service operation for day-to-day detailed change management and release management practices. Finally, continual service improvement enables continuous service improvements via monitoring and best practices.”
For insurance company CIOs, the connection between SOA and ITIL best practices is still in the formative stages.
“We’ve made a little bit of a connection between SOA and ITIL, but not heavily,” AFLAC’s Shields says. “We’re very process-oriented to begin with. ITIL is more for guidance.”
Carriers may begin to see SOA converge with ITIL as the two are employed to address increased competition and complexity.
“Success in applying ITIL to traditional IT infrastructure services is now leading to its application to other IT services, such as SOA, as part of an overall effort to improve the combined ratio,” Statkevicus says. “ITIL provides SOA design, implementation and governance efforts with a robust set of management processes that focus on delivering maximum business value, speeding time to deployment and reducing downtime through change management, and capacity and demand management.”
Forsythe’s Tainter observes that ITIL isn’t only about technical services, either. “ITIL has broken down ‘services’ into business services and technical services,” he explains. “Technical services are things such as e-mail, networking, data storage and Internet access. Business services would be things such as purchasing, billing and claims processes. You take and match the business and technical services up. ‘Do I need the e-mail service in order to do purchasing? What makes up the e-mail service?’ That’s really the SOA approach also.”
Best practices such as ITIL will help deliver SOA governance, which is essential to helping businesses identify the returns they are getting from their SOA project investments, says Tainter. “With processes in place, a service approach to your architecture, you can provide better metrics to your business,” he says. “Too often we just start collecting reports and start throwing them at the business. You need a better measurement strategy; you need operational metrics, combined into key performance indicators [KPIs]. As you do that, you’ll be able to discuss what the business is doing related to the architecture that you put in place.”
KPIs speak the language of the business, documenting how a particular technology project improved business results over a baseline measurement established prior to the implementation.
“If IT reports an application was up and running 99.9% of the time last month, someone from the sales side may push back and ask how many deals that represents. But, IT can’t tell from the data,” says Tainter. With a service approach as laid out within ITIL, an IT manager can report to the business that, for example, “‘We allowed you to process 100% of the deals that you put into the system last month,’” Tainter illustrates. “Now I can say, ‘Okay, we did 100, can we do 200?’ That’s a much better discussion with IT, rather than the typical details about applications, network bandwidth and data storage.”
Thus, ITIL becomes a means to better align SOA with ever-changing business goals, according to Primitive Logic’s Statkevicus. “ITIL is going to help drive efficiency throughout your SOA environment; it’s going to provide a better framework for defining your requirements in order to promote reuse, which will help reduce expenses and have a positive effect on your combined ratio,” he says.
“Your SOA initiative will have what it needs to create the associated architecture that supports that service,” Tainter agrees. “Working together, you get a lot more value out of both SOA and ITIL than you would just having one.”
Joe McKendrick is an author and consultant specializing in information technology based in Doylestown, Pa.
Selling SOA to Management
Many business executives may see the logic of moving to service-oriented architecture (SOA), but committing funding to initiate such projects is another story. Here are some tips from Joe McKendrick, author and consultant specializing in information technology, for selling the business on the benefits of SOA to secure funding:
Focus on the business benefit, not technical benefit: Business people don’t seek “SOA,” they seek cost-effective solutions to their problems. In presenting a business case, the three letters “SOA” probably shouldn’t even be mentioned. Focus on the solution without the technology: Look at a process that needs service-enabling and determine where the bottlenecks are, and how things would flow without technology. For example, a new sale may require input from the finance department, and the challenge may be determining a way to include financial processes as a subset of the overall transaction flow.
Think long term: SOA, at least initially, costs money. The larger the organization, the more money it’s going to cost. It actually may cost less to solve a business problem with conventional technology than to address it through a service-oriented architecture approach. Over the long run, as the SOA gets up and running and the stable of services grows, economies of scale kick in. The second time around, as another business process or unit is introduced to the interface or service, it’s a little cheaper, and so forth. But until then, there’s some up-front investments required that will be reflected in per-project costs.
Show how success will be measured: Key performance metrics, tied to specific areas of the business, will help calculate the return SOA is delivering in specific areas. Calculating return on investment need not be a complex undertaking. One expert, Ed Kourany, executive director of worldwide consulting for BEA Systems, San Jose, Calif., says that calculating the potential ROI of SOA doesn’t have to be an exacting exercise down to the penny, but the calculation can be a “just-good-enough number.” Arriving at ROI calculations is a complex undertaking. Kourany says he has seen three drivers to SOA value: business optimization, business agility and business innovation. Improving time to market is perhaps the greatest source of value that he has seen with his clients. One BEA client, Prudential, instituted a customer service portal that reduced call center time to the tune of more than $20 million a year. The key to measuring future SOA value delivered is to first establish a baseline of the company’s current costs and status, Kourany points out. “Where am I today?”
