Todays Software Is Built For Change
Constant change is a fact of life for all carriers. New regulatory requirements, new geographies and lines of business, acquisitions and divestitures, and adoption of recognized best practices all put stresses on core business processes–and the software systems that support them.
Often, the ability to modify enterprise systems is the major gating factor in a carrier's ability to respond effectively to changing business conditions.
For example, property insurers recently needed to institute special handling procedures for mold claims, but many were hindered by policy and claims systems where "mold" was not a recognized cause of loss.
The good news is that modern applications can be far more flexible than previous generations of software. By eliminating lengthy and risky programming changes and shrinking turnaround times from months or years to hours or days, new technologies provide a large competitive advantage to carriers who understand–and harness–their potential.
To understand how modern software designs allow far greater flexibility than found in systems even five years ago, it is important to recognize the three main areas in which software changes typically occur:
Changes to the data model and user interface
Changes to underlying business logic
Changes to integrations with other systems
Modifying a major software application used to require reprogramming, often in COBOL or assembly language. Whether done in-house or by an army of high-priced consultants, this was always risky, expensive and slow.
Modern systems use a very different approach. They separate out the definition of the data model, the user interface, the integration interfaces, and much of the business logic into easily modified configuration files. Instead of changing code, carriers can simply edit the configuration, a process that is far quicker and less risky.
Making this possible is challenging for software developers, but tremendously valuable for users. These techniques, which have been developed over the last several years, are now mature and well-proven. Whether building internally or purchasing from a vendor, it is essential for IT professionals to have a solid understanding of these new standards of application design.
Flexible applications are built on a foundation of metadata. Metadata is a flexible way of defining all the information that is used by an application.
A metadata document, describing the tables that are used to store information, is typically written in XML (eXtensible Markup Language), a standard language that is increasingly popular with both software developers and insurers. Metadata allows the data model to be changed when required, and allows those changes to be automatically and safely applied to the user interface and business logic.
Using metadata confers another important advantage: The application can automatically upgrade the data model from one version to the next. This dramatically reduces the risk and effort involved in migrating data from one version to another, making it possible to deploy new versions at any time. This is critically important both for software vendors, who need to deploy new versions to multiple customers, and for in-house applications that require frequent changes.
Building on metadata is so useful that it must now be considered a best practice. Vendors that do not provide a way to extend or modify the data model and user interface without programming, or that are unable to perform an automated version upgrade, are simply years behind the times.
Carriers have long used integration middleware to connect different systems. However, the hard work lies in extracting and translating the data that applications publish or receive. Metadata, again, can simplify this problem dramatically. The content and format of outbound messages can be specified in files which are interpreted by the application–and which can be changed without reprogramming. Similarly, inbound messages can be interpreted, streamlining the process of adapting to new inputs.
Providing no-programming mechanisms to modify the data model, extend the user interface and exchange data covers many of the changes that required reprogramming in older systems. But there are still cases where the underlying business logic has to change.
There are two main strategies available to minimize the amount of programming required. The first is to move business logic out of code and into a rule or workflow engine. These tools can be valuable, although generic versions can be difficult to adapt to the specific requirements of insurance. Solutions that provide a library of pre-built, insurance-specific functions can significantly reduce the risk and time involved in encoding and modifying business logic.
Sometimes, though, even these tools fall short and programming is required. Advanced systems provide well-defined interfaces that separate functional modules of the system and isolate code changes. In claims, for example, breaking out assignment, segmentation, validation and exception processing into self-contained modules makes it easier to meet specialized business requirements without placing other parts of the system at risk. Sophisticated systems now use Web services to permit these modules to reside on different physical servers and to be written in many computer languages.
Modern design approaches to building large-scale applications have changed the rules of the game for insurance carriers. By using metadata-driven data models, XML-based user interfaces and modular business logic, changes that used to take months or years can now be implemented in a matter of days. Carriers that understand and harness these new technologies will be able to respond to–and drive–market changes far more rapidly and at much lower cost than their more backward competitors.
John Seybold is chief technology officer of Guidewire Software, San Mateo, Calif. He can be reached at jseybold@guidewire.com.
Reproduced from National Underwriter Property & Casualty/Risk & Benefits Management Edition, March 12, 2004. Copyright 2004 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.