I was speaking with an IT executive recently about service-oriented architectures (SOA), and while he understood the grand vision of what SOA could bring to his company, he claimed it wasn't ready for "prime time." Probing a bit further, he told me it must not be ready because almost every vendor and consultant he spoke with painted a rosy picture of enterprise business value and then immediately did the "old bait and switch" and launched into a discussion of infrastructure "plumbing," with little connection to that vision.SOA promises insurers the ability to weave new systems and legacy applications together to support enterprise business processes across business units, product lines and country borders. Business process management (BPM) tools and business process execution language (BEPL) enable insurers to define business processes composed of Web services from new and legacy applications with minimal programming.
There is confusion about SOA and Web services in the insurance industry today. It is easy to become enrapt in the vision of flexible and efficient enterprise business processes flowing serenely across an SOA built around the latest insurance application or middleware solution. Unfortunately, insurers seeking that vision must deal with legacy application services enablement, defining high-level business process flow, negotiating service levels for Web services and support for mission-critical distributed services monitoring.
In today's business climate, insurance IT executives can't afford to wait out the SOA confusion. The good news is that value is there and the quest is worthwhile. Here are some things to think about:
It's still all about enterprise application architecture. SOA is at its best when implemented at the business process level, crossing traditional application system boundaries. A Web service that enables a specific application to use multiple front ends (i.e. Web page, voice response, legacy apps) to update a customer record is useful, but a higher level service that enables any business process within the enterprise to interact with common customer data in a controlled and audited manner is much more valuable. Be sure the vendor understands the scope of your enterprise business processes and can deliver services that are generally useful to your business. If you haven't defined enterprise business process maps, it is impossible to make good decisions about the required granularity and scope of high-level services.
Web services is a clearly defined technical concept, but "service oriented" is ambiguous and can be confusing. A services model can be implemented without a Web services protocol compliance. When looking at business applications, development tools and implementation frameworks, understand what you are actually buying. Current "service orientation" applications fall into three categories:
* Proprietary applications. Some very good applications are designed using a conceptual services model. These services are never exposed to other applications, do not conform to ACORD or other standards and give the enterprise no SOA "leverage."
* EJB applications. Enterprise Java beans (EJBs) are a great foundation for developing Web services but are not automatically available as a Web service. EJBs must be designed with Web services in mind and then defined to the enterprise using Web services description language (WSDL) deployed on a services middleware solution.
* Providers of enterprise Web services. Applications that provide true business-oriented Web services have clearly defined functions (i.e. update customer data, pay premium, initiate claim) with the same safeguards and edits a user would find in the application itself. Services are clearly documented and delivered with the appropriate WSDL.
Services need to be orchestrated and managed to be useful. Web services must live within a framework that supports service advertising, delivery, monitoring and maintenance. These frameworks are not part of the application, requiring additional investment in infrastructure. When evaluating middleware frameworks to support your SOA environment, look beyond basic middleware functionality and service cataloging, and require business process design and management tools, BEPL engine support, content management and Web-service monitoring as part of the package.
SOA and Web services provide a huge opportunity for insurers to leverage their existing and new applications, increase business flexibility and reduce cost.
IT leaders must be very careful in vetting applications, middleware partners and systems integrators to avoid the ambiguity that still plagues this space and ensure that the implementation is aligned with the vision.
Chuck Johnston is senior director, financial services for Oracle Corp., Redwood Shores, Calif.
