The first mechanical typewriter was invented in 1867. Shortly thereafter Mark Twain submitted the first typewritten manuscript to a publisher. You may be surprised to know that only weeks ago the last factory manufacturing mechanical typewriters closed its doors, driven into obsolescence by the computer and word processor. The factory in Mumbai, India, stopped production in 2009, and its inventory has dwindled to just a few hundred machines, most of them Arabic-language models. No more will be made.
Although typewriters became obsolete years ago in the West, they were still common in India, until recently. This is a story that has played out again and again over the course of human progress.
A new invention is developed, generates creativity and efficiency, and is superseded by superior technology within a few generations; or as happens nowadays, within years.
I recall just a few years ago predicting to the CEO of a legacy software company that no more COBOL-based systems would be sold in the insurance vertical. The absolute nature of the prediction may have been premature, but the obvious trend was undeniable.
Just as we moved from mechanical typewriters to word-processing software so we have moved from “hard-coded”, COBOL-based application systems to a new and superior generation of highly configurable systems.
There are no definitive numbers for how many vendor systems carriers bought in 2010. One reasonable estimate is that property/casualty carriers bought about 60 policy administration system solutions. As far as I can estimate at least a third of those deals were won by only four or five vendors. There are about 50 policy vendors in the P&C market.
So, if approximately 20 deals went to four or five vendors then 40 deals went to 45 vendors, an average of 0.89 deals each. Many of these vendors sold zero deals in 2010, and a few sold more than one. From what I can tell the modern, highly configurable vendors are the ones making the sales while legacy vendors fall further behind.
Much has been made in recent years of the rise of this new generation of software vendors that have taken a new and better approach to writing core insurance application software. These vendors, who are software engineers before they are insurance domain experts, analyzed the problems inherent in the insurance industry—complex, data-intensive products; line of business differences; state variations in pricing, product, and workflow; and ongoing compliance and reporting requirements—and concluded that a fundamentally new and better way of building and maintaining application systems was required.
A way that reduced time-to-market, controlled the drag created by maintenance overhead, and afforded the business users greater involvement and some degree of autonomy in the systems enhancement process.
For all their genuine differences, these vendors have essentially implemented versions of the same strategy.
First, vendors build a set of development tools that are flexible, responsive and support (relatively) rapid system enhancement without having to (except on rare occasions) step outside the development environment and write computer code.
The basic formulation is that the vendor uses Java, or its Microsoft alternative, to build the development tools.
Second, the vendor uses the development tools, which are easier, quicker and more flexible than writing code, to build insurance applications (the modern equivalent of the “packages” vendors used to market).
Third, the vendor, its customer, and any partners enhance and modify the insurance application during implementation and maintenance, again using the development tool kit.
When discussing these tool kits vendors commonly use two words: rules and engines; such as underwriting rules engine, rating engine, workflow engine, integration engine, etc. The implication is that something (the engine) is doing some of the work previously done by the computer programmer, which reduces workload and speeds delivery.
And so the implementation paradigm has shifted from one involving extensive program coding to one of configuration, which is the writing of rules and the coding of data that drives system decision making.
Along with this paradigm shift comes reduced implementation timeframes, costs and risks, streamlined ongoing maintenance and generally more responsive systems.
The term commonly used to describe software with these characteristics is highly configurable. The term is everywhere in the literature and it’s what every vendor system now claims to be. As we noted above in terms of market growth and acceptance it’s also where the action is.
So, given that every software vendor now claims their solution to be highly configurable how do you know who is and who isn’t? There are a few characteristics that you should look for in assessing the competing claims of different vendors to have a highly configurable system. Here are the important ones:
The system should have a 100 percent Web client that ensures that no software will be installed on end-user desktops. Preferably these clients would run under Internet Explorer, Safari, FireFox or any other emerging browser.
The oldest and most established of the application engines, the rating component should allow product development and IT staff members to build pricing algorithms of any reasonable degree of sophistication and then load data (rate pages) that provide values to the variables in the algorithms.
Basic requirements include the ability to store and reuse algorithms, and create variations across geographies and time. Some highly configurable systems have their own rating engine, some don’t; in either case it is reasonable to expect that the vendor’s system can readily integrate to a third-party product via Web services.
The notion of an insurance product engine has been around for at least 20 years, but it is only in recent years that the underlying technology has become powerful enough to support such an entity. By analogy with the rating engine a product engine is capable of storing rules and data that define the coverages, limits, deductibles and rules that constitute an insurance product.
Product definitions should support geographic and temporal variations and should be capable of reuse. Unlike rating engines, product engines have not achieved a degree of autonomy from the rest of the policy system. With one qualified exception, no vendor sells a best-of-breed product engine.
Workflow/Business Process Engine
The third key application system component is the rules engine that supports the definition, variation and change over time of all the myriad rules that control the processing behavior for various transactions, which occur for different lines of business in different regulatory environments that change over time.
Insurance companies believe they need the flexibility to continually refine their core business logic in response to changing business needs. Interacting with the rating and product engines, the workflow engine gives the carrier company-control over the critical steps in their processes, including underwriting, policy processing, and compliance.
The workflow engine gives insurers the ability to define insurance processes that run across multiple specific activities and actors, with exception and escalation processing supported as appropriate.
In order for the carrier to create a highly-configured solution it must have the ability to tailor the system to its unique business needs. To support this, the vendor’s platform must allow customers to extend the application logic (usually via the addition or enhancement of existing rules), the application data model and the data entry and enquiry screens.
Commonly the data model and screens are extended using logical, and hopefully understandable, XML files. Automated database modification usually employs the use of metadata, obviating the need to write custom SQL commands. The user-friendliness of the configuration environment varies by vendor from very intuitive studio environments to fairly challenging technical environments.
However, two points are important with reference to configuration: the first is that content is much more important than style; the power and extensibility of the configuration environment is much more important than it’s look and feel. Second, and the reason for the first, is that these toolkits are still largely the domain of IT professionals, not business users, so simplicity is secondary to efficacy.
A core insurance application such as a policy administration system may have anything from 20 to 100 integration points; some of most obvious and important include claims, billing, statistical reporting/data warehousing, print solutions, third party data systems and agency systems.
So, the policy administration system must integrate seamlessly with many different applications, which are built in a wide range of technologies (or with an enterprise service technology). The vendor should provide a variety of integration mechanisms, including a Web services API, event-based messaging, and the ability to add integration adapters at any point in the application. Data exchange should be supported in any format, including ACORD XML or IAA.
Highly configurable systems are a big deal for companies today. They are here to stay and are actively in the process of superseding the rigid COBOL legacy applications that still exist in many insurance carriers.
Given the complexity, risk and length of legacy replacement projects it may take another generation to finally establish highly configurable systems as the industry standard, but it will inevitably happen, only to be superseded in turn by the next wave of software advances. After all, before the mechanical typewriter there was the quill pen.
George Grieve is CEO for CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 210-887-6423.
The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.