Web Services Facilitate Collaboration
"What are Web services and why should I care about them?"
This is the question everyone is asking lately. Given the over-hyped promises of so many recent technologies, it almost seems wise to dismiss any new technology on general principles. Id like to take a few minutes of your valuable time to convince you otherwise.
Lets define just what Web services is actually supposed to accomplish and see if its a good fit for insurance automation systems.
Web services is a technology infrastructure that allows computer applications to operate in a collaborative mannerwith the emphasis on collaborative.
The dictionary defines collaborative as "to work together." Web services is technology that allows two or more applications operating on different computers in different locations to connect and "work together" in order to accomplish a useful task.
The ultimate Web services technology to date is the Web browser. It is a Web services application that allows unprecedented connectivity to and between new and existing computer applications.
From a technology viewpoint a Web service is an application program to perform a common task that can be easily shared by other applications, connected together by a network. Now, the network does not have to be the Webit can be any kind of public or private networkbut with the Webs diverse and extensive connectivity and low cost it is often the most effective way to provide a remote service.
An insurance policy is itself a highly collaborative document. Collaboration in how information is acquired to construct the policycollaboration in how information is combined to create the policy, and collaboration in how the policy is then distributed to its constituents.
Insurance automation has never been particularly collaborative. Just ask any agent who wants an industry-wide comparative rating system, or a carrier that needs MVR information, or a consumer who wants to see their billing status, or an adjuster who needs to see coverages on a policy while in the field, or a statistical manager who needs to update the agent with every policy activity. Each of these and similar business tasks requires significant manual efforts and generates delays that can be eliminated through Web services.
Web services can assist in organizing information sources and users, such as consumers, agents, portals or affinity groups, to directly connect with the system that processes that data.
Wouldnt it be nice to write a policy primarily by identifying the policyholder and the risk, then letting the system fill in the majority of the policy data accurately and without costly effort? This will make consumer-based quotes and new business applications far more practical and accurate, not to mention economic.
Much information is already available online and more is becoming available everyday. As an example, systems may be configured so that the presentation of an address or VIN number will return substantial amounts of information that is needed to create and underwrite the policy.
Examples of policy and underwriting information and actions include the ability to get an MVR and the ability to check credit, address-based data, territory, protection class and flood plane.
Making rating a standalone Web service allows not only a clean interface between your rating system and policy administration system, but also allows you the option to expose your rates to agency systems, consumer quoting systems, Internet portals, human resource systems, affinity groups, and any other source of business that can be reached via a network.
Youll also have information and processes to convert currencies, translate between languages and update the local registry with required information.
In addition, youll have the ability to distribute the policy by connecting to remote printing sites.
In the past, computer applications were written in a centralized, monolithic manner. All information necessary to process a policy was entered by a user or supplied in a fixed interface from a known source, usually another program in the same system. Information from disparate sources was requested in "batches" from outside systems. It was received and processed in daily or weekly "batch cycles" from consistent sources.
Web services are developed on the basis that the origin and destination of any request may be different computer applicationsfor example, different motor vehicle record providers processing requests for unique policy management systems. The request and responses must be constructed with certain rules that govern how it operates, but these rules (standards) must be quite flexible to adapt to the different applications and the way they process.
Think of how individual browsers have the flexibility to receive, display and send information between millions of diverse Web sites worldwide. All the sites are based on a relatively straightforward set of standards developed around HTML.
This potential Tower of Babel is managed using a protocol called eXtensible Markup Language, more commonly known as XML. XML is a data coding structure that is self-definingmeaning that the data itself includes information about what is contained, where it is and what it looks like (alphabetic/numeric/length, etc.). In fact, the HTML that makes Web sites so flexible and ubiquitous is a sub-set of XML.
The property and casualty insurance business is particularly blessed by already having an XML standard through the ACORD standards group. This paradigm will need to evolve from a full transaction standard for new business, endorsements, cancellations, etc., to a more granular standard based upon individual activities such as an MVR request, a rating request, a territory lookup or a protection class lookup. These changes are evolutionary, but for once, the insurance automation industry is miles ahead of most other industries.
XML data is sent and received through Web services. Not surprisingly, different software vendors have developed their own suites of Web service management tools. Examples are IBMs WebSphere, Microsofts .NET and Suns SUN ONE. These Web service protocols can be made to work together, but it is generally easier to stay within a family.
Web services is a new technology and as such, standards and supporting processes are still evolving. Security can be a concern and highly confidential transactions should not yet be sent over the public Internet. Nevertheless, these issues will be resolved. In the meantime, there is much to be gained by moving into a Web service architecture in your automation solution.
The technology benefit is the real time, low-cost access provided by the Internet that encourages data and service providers to make their information available on a "pay by the slice basis."
Web services will not solve world hunger but they will allow the next generation of property and casualty applications to work much more effectively. They will simplify your processing, diminish errors, and increase your premiums due to more accurate underwriting. Most importantly, Web Services can accelerate the goal of once and done processing at the point of service.
Charles J. Boodro is chief technology officer at AscendantOne Inc. (www.AscendantOne.com), a p-c rating/underwriting, policy and account management solution provider based in Nashua, N.H. He can be reached at chuckboodro@ascendantone.com.
Reproduced from National Underwriter Property & Casualty/Risk & Benefits Management Edition, July 29, 2002. Copyright 2002 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.