There's probably been more discussion about Web services than any other technology topic in the trade magazines lately. And the debate abides: Is it hype, or will Web services truly add business value to the insurance industry?It isn't hype, but only full Web services, those offering a common interface for all systems and applications, can make the potential of Web services a reality.
Additionally, those systems and applications must be tightly yoked with a service-oriented architecture (SOA), the foundation that enables the different pieces of the puzzle-the business services-to work together.
Web services are already starting to make it easier and more efficient for insurers to conduct business, and we're at the beginning of the revolution.
The opportunities, and the challenges, are immense. The property/casualty industry has to integrate more complex moving parts and connect more parties than perhaps any other industry.
It starts with quoting, which is handled by the insurer or by an agent or broker remotely. Quote information is passed to the insurers' or managing general agency's underwriting system
Once the policy is issued, the insurer tracks claims against it, reinsures it, files and maintains rates and forms with the various states and regulatory bureaus, fulfills regulatory and financial reporting requirements, generates bills, and pays commissions.
As a result, many disparate, geographically dispersed systems need to talk to one another.
Connecting services
To connect these services, the industry has turned to SOA. Yet, importing and exporting data without Web services has remained challenging because information must be converted to flow from one system to another. This requires building and maintaining application protocol interfaces (APIs), and when the insurer brings a new product to market, the APIs must be adjusted, causing delay and expense.
Even today, data sometimes must be re-keyed instead of flowing automatically from system to system.
Further, integrating various services requires special networks. And extensive work must be done to ensure that services talk to each other.
The Internet, which can serve as a ubiquitous, standard network, is dramatically changing that by enabling the transparent flow of data between different services or systems.
Web services, running in an SOA, allow programs written in different programming languages and on different platforms to communicate and share data through standard Internet protocols such as HTTP and payload language XML.
Also required is the messaging mechanism-called simple object access protocol-which transfers data, and Web services description language, which describes the services being made available.
Because Web services allow data to be communicated via the Internet, communication can be conducted without APIs and without invasive integration with each company's IT shop or behind each firewall.
Beyond the efficiencies of using the Internet as a medium, Web services achieve operational efficiencies. Instead of using a graphical user interface, Web services use a programmatic interface, so applications communicate, not users.
And since all data is tagged in XML, communication between applications doesn't depend on any particular operating system or programming language.
If need be, a graphical user interface can be added to Web services (or vice versa) to give users specific functionality. But there is no operational dependence on the user interface.
Web services lets SOA reach its full potential. There's no need to worry about the nuts and bolts of each service.
For instance, if you're using a service such as printing or underwriting, you don't need to know how that service works internally. You only need to be able to access and use it whenever and wherever you require.
Technology agnostic
That's why Web services are described as "technology agnostic."
It doesn't matter what kind of hardware or software you're using. It doesn't matter in what language your applications are programmed. If you have full Web services as your toolset in conjunction with SOA, you can connect all applications and services running on all platforms.
And you can mix and match as you like. For instance, the broker and the insurer may be using different rating engines. Both can be integrated easily.
The result is that IT professionals no longer have to deal with low-level "nuts-and-bolts" interface problems.
Both vendors and company IT experts can concentrate on enhancing various services-continually improving rating, underwriting, policy production, billing, reinsurance, and reporting systems. And they can expand access to agents, brokers, reinsurers, regulators, and even insureds, when appropriate.
The dream of universal connectivity of insurance systems, both internal and external, has evolved beyond the hype. It's a whole new way of thinking about automating the industry. And it's a whole lot more than hype.
H. Alex Aminian is senior vice president and chief technology officer at Insurity Inc., Hartford, Conn.
