Claims from a core perspective: Strategic considerations in enterprise deployments

Introduction
Of the multiple business disciplines found in a P&C carrier –  underwriting, policy administration, billing, reinsurance, client management, and claims – claims has traditionally been the underfed stepchild. The P&C insurance industry is no exception to the rule that enterprises invest enthusiastically in revenue generation and only reluctantly in their cost centers.  Guidewire Software, which was founded as a provider of next-generation P&C systems, has argued for years that this bias overlooks the significant economic potential locked in claims organizations constrained by legacy system environments.  This argument was built on the consulting work of firms such as McKinsey and Accenture, who quantified for their P&C clients that process inefficiency and indemnity “leakage” through systematic handling errors could be costing their organizations several points of combined ratio.  The root cause of many of these errors was a system environment that underserved the needs of claims adjusters and managers for data, workflow, analysis, and best practice enforcement.  Guidewire ClaimCenter is a modern claim system directly targeting these challenges.
Through countless discussions with a broad cross-section of carriers domestically and internationally since 2001, however, Guidewire has come to identify the challenge of modernizing claims technology as just one part of a larger story about the future of P&C core systems overall.  Core systems – the transactional systems-of-record at the heart of a carrier’s business processes – are the immensely complex “mother ships” around which many ancillary sub-systems extract and feed data.  Guidewire has arrived at the estimate that approximately 90% of the global P&C industry relies on legacy core systems: 15-30 years old, mainframe-based, written in COBOL, and sustaining the minimum enhancements necessary to continue processing business.
The encroaching obsolescence of these systems imposes three strategic dilemmas on today’s CIO:  First, how to distribute finite IT resources between current and new systems overall?  Second, in what sequence should business areas be targeted for modernization?  Third, should investment in new systems take the form of building or buying new systems?  Whether, and how, to modernize a carrier’s claims technology are questions that must be answered in this larger enterprise context.
The conclusions we shall reach are: First, it is vital that carriers develop a long-term strategy for core system management and eventual replacement.  Second, that the inherent challenges of initiating and succeeding in core system projects often support beginning with claims versus other business domains.  Third, that the evolution of software technology and the industry track record of P&C core system projects argue strongly for “buying” versus “building” new systems.
The case for core system replacement
Any consideration of these questions should start with the null hypothesis, why not forego investment in future core system platforms altogether?  A system’s age and legacy status alone do not render the case for replacement open-and-shut.  Optimized for high transaction volumes and tested by hundreds or thousands of person-years of use, the legacy generation of core systems that replaced the filing cabinets now set a high standard for reliability and performance that any new system must meet or exceed.
There are four broad reasons to undertake core system replacement.
First, legacy systems have become structural obstacles to higher performance in every processing domain of a P&C carrier.  Precisely because they were designed as transaction engines, legacy core systems provide minimal support for the evaluative and interactive dimensions of P&C insurance work.  In the best practices paradigm of the 70s and 80s, the human actor – the underwriter, adjuster, or billing specialist, for example – relied on paper files, notes, phone calls, and his own judgment to make decisions and communicate externally, while only the transaction execution was left to the system.  Today, virtually every carrier aspires to a significantly more automated and controlled business environment in which routine decisions and many standard tasks are handled without involving human action.  While the specifics vary widely by business process and organization, some key examples are:

• Rule-based automatic evaluation of risk quality, claim severity, fraud and litigation potential;

• Automated segmentation, division, and assignment of work on individual cases to different specialists;

• Automated workflow supporting complex, high-volume, rule-driven processes such as new submissions, recoveries, and policy renewals;

• Exception-based monitoring of data quality and service level achievement;

• Automated support of complex cross-functional business models such as loss-sensitive programs and aggregate policy limits; and

• Real-time or near real-time presentation of operational and financial data tailored appropriately for each level in the supervisory hierarchy.

Target enhancements such as these reflect the increasing adoption by P&C carriers of process management philosophies pioneered by manufacturing industries.  It is now typical for P&C executives to measure their operations in terms of quality control, productivity, cycle time, and customer service level attainment – beyond the traditional insurance metrics of sales production and underwriting profit. Optimized for batch transaction processing, legacy core systems are poorly architected to support this more data-intensive, business-rule-driven, process automation paradigm.
A second, related reason for replacement is core system flexibility.  Legacy architectures are ill-equipped to support continuous change.  In any COBOL-based system, business logic and data structures are densely packed in procedural code.  Any change to logic or data – or to higher-level business entities such as products, customer segments, and billing plans – requires extensive custom design and development work.  Consequently, even the most agile organizations expend months or even years of expensive effort to respond to changing business and regulatory requirements.  This rigidity is inherent in the architecture of legacy system environments and has long been endured simply as a cost of doing business.  Providing core system flexibility for products, data, and processes in an environment of continuous business change is hence a key requirement domain for the next generation of core systems.
Third, while the Internet has not yet dramatically transformed P&C distribution, it has raised expectations for new models of self-service by policyholders and producers.  Compared to its peers in retail and financial services, the P&C industry has much further to go to enable its customers and distribution channels to manage interactions through web-based self-service. True “no-touch” models for new business, endorsement processing, billing, account management, and claim lodgment are still early in their development – but few question that they will become the eventual norm.  This introduces a new category of end-user and integration requirements on a generation of systems designed long before the Internet was a household word.  It is only through numerous compromises and ingenuity that a batch-based, code-driven, monolithic architecture can serve as the transactional platform for a widely distributed population of ad hoc end users expecting an Amazon.com-like experience.
The final motivation for core system replacement is human-, not system-related.  The language of legacy core systems is overwhelmingly COBOL, which has been almost entirely displaced throughout the IT and software industries as a programming language.  Very few university computer science curricula offer COBOL programming classes today since object-oriented and web-native architectures have become the norm for enterprise software development.  Moreover, because legacy systems are adapted only through custom programming, each has become a unique artifact quilted through countless waves of modification and enhancement.  Consequently, it is all too typical for even the largest carriers to have the true understanding of the workings of its core systems concentrated in the heads of a handful of employees approaching retirement.  Addressing this key point of enterprise risk provides for many CIOs the most “non-negotiable” motivation for investing in future core system platforms that both align with evolved technology standards and are fundamentally more transparent than procedural languages such as COBOL.
Over the next decade, P&C carriers will be split into two categories: those who respond to these four motivations – process control/automation, core system flexibility, self-service enablement, the retiring legacy system knowledge pool – and those who do not.  Those who do respond will invest steadily in new core systems with fundamentally different architectures, while those who do not will continue to make tactical fixes that extend the life of, but do not ever aspire to replace, existing systems. These performance trajectories of these two categories will be close in the early years of this transformation.  Over time, however, they will diverge dramatically as those carriers who successfully make the transition to next generation core system environments are able to deploy fundamentally more automated and efficient business processes while providing customers and agents more compelling products and web-based service models.  If this is true, carriers who bet on our “null hypothesis” years earlier will find that working the traditional levers of P&C performance – such underwriting focus, expense discipline, and claims leakage management – will be inadequate in themselves to support competitiveness with the other group.
Investing in core system replacement: three key challenges
Concluding that to neglect investment in core system replacement would be foolhardy only scratches the surface of deciding how and how much to invest.  Because carriers vary widely in their current states, quantifying a “proper” range of investment for all organizations is of little value.  But there are relevant generalizations: Guidewire’s experience over dozens of core system projects has uncovered three key challenges that typically confound carriers as they grapple with core system replacement.
First, unlike more tactical IT projects, core system initiatives require long timeframes. The full transition to a new transactional system-of-record will take multiple years for all but the simplest of enterprise IT landscapes.  In order for a project phase to deliver meaningful value, its scope must encompass a large portion of the legacy system, if not complete replacement.  This entails the broad canvassing of end user and management requirements, redesign of business processes, development of numerous integration interfaces, and a testing period which can amount to a quarter or more of the total project duration.  Guidewire’s own experience has been that – regardless of the technology involved – the sheer complexity of current state business and system environments entail standard project durations of one to two years for a single phase project on a single core system area.  And since there are multiple core systems areas, time spans as long as five to ten years would not be unreasonable for a P&C enterprise to achieve complete sunset of its legacy system environments.
Such a long horizon of change gives rise to multiple challenges.  Rushing a project to achieve an arbitrarily designated completion date and allowing a project to limp along interminably are opposite but equally dangerous pitfalls.  There is no substitute for the hard analytical work of defining an achievable scope that delivers meaningful business value and then rigorously estimating how long it will take to complete with high quality.  For an organization to “internalize” and clear-sightedly accept the duration and level of effort required to replace its core systems is the most vital step it can take toward eventual success.  Yet this challenge is heightened by the inevitably high expectations of business end users and management generated by the prolonged effort invested in a core system project.  These expectations may not appreciate the extensive amount of foundational technology work necessary to define a new architecture and to achieve functional parity (let alone superiority) with the status quo.  Because project teams are pressured by these expectations, there is a great risk that decisions to “get something delivered” will trump making the right long-term investment.  As will be discussed further below, this is one of the most important motivations to begin with a properly architected vendor-delivered product that provides a concrete representation of the end-state.
A second challenge arises from the blind spots of corporate decision making and financial planning. While the requirements of quantitative business cases, ROI models, projections of payback periods, and cost-benefit analyses all have their place in imposing financial discipline on capital investment, they are ironically the most limited when the stakes of an initiative are the highest. To take an analogy from everyday life, tactical financial decisions such as whether to refinance a mortgage, invest in a mutual fund, or pay for the help of a tax accountant are readily estimated in their cost and benefit.  In contrast, decisions which have far more profound effects on one’s financial well-being – such as paying for a university education or changing one’s career – are virtually impossible to quantify. The costs may be clear, but the benefits are open-ended and include the option value of new opportunities not clearly visible from the starting point.
Similarly, core system projects fit uncomfortably into the framework of financial analyses appropriate for tactical system modifications.  A cost-benefit model well-suited to estimate the value of avoiding regulatory fines from a missing data element will typically struggle to quantify (or even identify) the value of such open-ended benefits as improving product and pricing flexibility, enhancing claim quality by superior data capture and presentation, and increasing retention of skilled personnel by creating a more automated and professionally fulfilling work environment. In deciding the proper allocation of resources between current and future core systems, far-sighted organizations overcome this quantification challenge without compromising financial discipline, while “follower” organizations often talk themselves out of all but the most tactical of system fixes.
The gravest mistake is to undertake a half-hearted core system augmentation effort which may deliver some short-term benefit, but which brings no closer the eventual retirement of the legacy core system.  While it can be perfectly appropriate to decide consciously on tactical enhancement versus a strategic replacement initiative, too often short management attention spans and the pressures of internal funding abandon a once ambitiously scoped project at the “Phase 1 front-end” stage, thereby only complicating the IT landscape in the long-run.  That so many P&C IT environments are littered with orphaned “Phase 1” systems is a testament to the difficulty of planning and following through on core system replacement.
The third challenge in core system replacement arises from the disparity in skills required for the maintenance of existing systems versus the development of new systems.  In Guidewire’s experience, even large IT organizations that have successfully maintained and evolved a legacy core system platform for decades often find themselves lacking the skills to design a new system from the ground up.  Analogous to a team of mechanics proficient at repairing cars but unequipped to design new ones, most P&C IT teams are neither trained nor organized to design and develop a modern, web-native enterprise application.  In part this is because they lack expertise in newer software technology disciplines such as object-oriented programming in languages such as Java, web-based user interface design (including recent advances such as AJAX), clustered architectures, relational object mapping, metadata-based data model design, automated performance tuning and tooling, and web security infrastructure.
More important than specific technology knowledge, however, is the inexperience and missing organizational structures to manage foundational application development.  For example, in most P&C organizations, the task of framing requirements for fulfillment by a development team rests on the shoulders of “business analysts.”  These analysts are often drawn from the ranks of former business end users, who draw upon on their field experience to articulate necessary changes to existing systems.  The division of labor between the business analyst and the technical staff serves maintenance needs well, since requirements are always incremental to an existing system framework.  Developing a core system from the ground up, however, requires much deeper technical design skills – namely, the synthesis of a vast set of business and technical requirements into a coherent and achievable system design.  Because software companies live or die by the quality of their software products, they recruit, cultivate, and reward this “product manager” skill.  It is less common for P&C carriers to do the same.
A core system replacement initiative must therefore plan for a multi-year sustained effort, achieve internal justification without complete quantification of value, and assemble an entirely new corpus of skills even before it gets off the ground.  In light of such challenges, Guidewire strongly recommends to carriers contemplating different core system initiatives to choose based on maximizing the chance of project success –rather than by business preference or even by the potential value to be achieved.  After all, a failed project is worse than useless, no matter how valuable the starting aspirations.  From this perspective, claims projects often have key advantages over projects in other P&C business domains.  In particular, claims projects involve shorter timeframes, fewer integration points, and simpler business processes than policy administration replacement projects.
“Buy” versus “build”
This leads us to the last of the dilemmas posed earlier: should investment in core systems take the form of implementing a core system product from a software provider, or custom developing a solution (either alone or with the help of a consulting partner)?  That is, to buy or to build?
Historically, simple necessity answered this question for many P&C carriers: either building an application was simply impossible given available resources, or there was no procurable packaged solution that would meet the need.  While this may still be the case for many, there have been developments on both the “buy” and “build” sides that render the question potentially more complex than before.  On the “build side,” the emergence of numerous offshore development firms offer to smaller carriers access to large pools of technical labor. Also, the evolution of certain software components, such as workflow tools, rules engines, application servers, and object-relational mapping tools, seem to offer a set of building blocks that could accelerate internal development efforts. On the “buy” side, the emergence of a new breed of vendors has proven that highly configurable packaged core system applications can support the varied needs of a wide array of P&C carriers.
We believe that, appearances of “balance” notwithstanding, technology advances of the last decade overwhelmingly favor P&C carriers buying over building core systems. Specialized software providers have numerous advantages over any custom development initiative.  Let us consider why.
First, the huge costs of developing these enterprise software applications can be distributed over numerous customers and amortized over years of distinct initiatives, rather than concentrated into a single project.  Software companies must justify their development expense not by potential business benefit to any given project, but by the tougher standard of market adoption: either the application proves itself in the market and is broadly adopted, or it fails and never repays its cost of development. As an example, Guidewire’s market success has been built on a product-based strategy of distributing the cost of the 150 person-years of development invested to date in each application (PolicyCenter, ClaimCenter, and BillingCenter) over its growing customer base.  As in many other domains, the pressure of the free market to meet demand as fully as possible is a much more efficient and accurate guide than any management directive.
Second, software companies are better equipped to recruit and mobilize the skilled engineering teams necessary for modern enterprise software development. As business processes, integration requirements, and automation expectations have risen, the minimal “table stakes” for a mission-critical enterprise system have steadily risen.  Today, the technology requirements of a P&C core system include:

• Clustered and multi-threaded architecture to support massive horizontal scalability;

• A metadata-based data model enabling unlimited extension and automated upgrade;

• User interface frameworks supporting building large numbers of screens with complex components such as sortable listviews, filtered typelists, cross-field validation and embedded functional “widgets”;

• Support for complex screen flows with extensible business logic;

• Security and community modeling enabling a rich hierarchy of users, groups, and roles, including external users and organizations;

• An integration layer supporting multiple integration channels including event-based messaging, web services, custom adapters, and dedicated APIs;

• Security infrastructure and design principles to thwart sophisticated new models of Internet-based security attacks; and

• Native performance testing and tuning tools, including dedicated test harness, automated test suite, and large volumes of sample data.

Despite being well-established, standards such as J2EE and .NET do not yet provide extensive enough development frameworks simply to dive in defining business logic and creating screens.  To fulfill these “platform-level” requirements, a development team cannot merely select attributes from a menu of choices.  Rather, many person-years of technically demanding foundational work must be invested before end user-visible functional work can even begin.  Most P&C carriers have rationally concluded that there is little value and significant risk to re-invent the wheel at this foundational level, unless there were good reason to believe no vendor has gotten it right.
A third consideration is flexibility.  If indeed business process and product flexibility are key motivations for undertaking core system replacement, replacement systems must support dramatically greater and easier adaptability to changing business requirements.  This is an especially vital requirement in light of the high switching costs, and therefore extended target lifespan, of core systems.  In short, a new policy administration or claims system must not only meet the universe of business requirements specified today, it must be architected to maximize support of future requirements not yet specified, or even imagined.  The requirement for generality, therefore, is not merely the concern of software vendors striving to meet as broad a segment of the market as possible; rather, it should be an inherent requirement of every organization maximizing the longevity of its IT investments.  Unlike the legacy generation of core systems, modern applications can be architected for upgradeability and configurability in virtually all its key dimensions: user interface, business logic, data model, organizational hierarchy, screen flows, and so forth.  Building for this level of future adaptability imposes a considerable additional development burden – a burden which both the software engineering skills and investment disposition of most P&C carriers are ill-equipped to bear.
Fourth, the buy decision supports a logical division of labor between the competencies of a software vendor and a carrier’s IT organization.  The internal resources who thoroughly understand the business and system environment can focus on requirements gathering, legacy system documentation, business process re-design, and planning for system migration while the software vendor remains accountable for system architecture, product features, product performance and quality, and integration.  Because business analyst personnel and end users are on the more solid terrain of interacting with a working base application, their input and gap analysis can be fine-grained and iterative, rather than high-level and theoretical.  Because legacy system experts can write integration code against a working system, they can proceed more rapidly to testing actual integration, rather than planning potential code on whiteboards. Because the vendor application has an implementation history at other customers, the joint implementation team can estimate project tasks and overall duration with far greater confidence.  And because the software vendor is highly motivated to continue to evolve the application, an upgrade path of enhancement avoids the functional stagnation inevitable in a custom development effort which must eventually declare victory or failure.
Fifth, a vendor solution can offer a surer course to true core system replacement than a build effort which may lose its will before achieving the goal.  For all but the smallest of P&C carriers, both buy and build approaches will typically require multiple phases – organized by function, line of business, or business unit – before a core system and all its integrations can be replaced.  Regardless of how many phases are planned along the implementation path at any given customer, leading-edge applications are designed with the functional target of assuming full system-of-record responsibility, eliminating the technology risk of a “stranded Phase 1” lacking the functionality or architectural foundation to replace the legacy system with which it may initially coexist.
In the aggregate, these five considerations have less to do with cost than risk. Because of the scale and effort of any core system project, the consequences of even an “inexpensive” failure can exact a devastating cost on an organization’s focus, morale, and future competitiveness. And if it is true that replacement of legacy core systems is not a luxury but a necessity over the coming decade, then no organization can afford to spend years in an effort that brings it no closer to its next generation system platform.  Hence, while any potential “build” effort is limited only by an organization’s optimism and imagination, the inherent risk and complexity of a core system development heavily weight the tangible assets and implementation track record – even if limited – of a packaged application built on the right architecture.
Conclusion: Finding the right technology partner
The multiple advantages of “buy” just described, of course, assume that a quality vendor alternative is available at all.  Guidewire Software itself was founded precisely because of its founders’ conviction that the P&C industry had in fact been underserved by software solutions during the past decade, and that the industry would need next-generation core systems to replace the faithful, but superannuated mainframe systems supporting all of its core processing.  Hence, in arguing for the long-term urgency of legacy replacement and the clear advantages of buying rather than building, this paper does not suggest that carriers have an abundance of equally good options.  Guidewire believes it may be unique in approaching the challenge of delivering the next generation of policy, claims, and billing systems to the P&C industry as a lifetime goal worthy of assembling world-class development and implementation teams to serve.

---

Marcus Ryu is co-founder and Vice President of Strategy and New Products for Guidewire Software, Inc. Guidewire is an enterprise software company focused entirely on the development and delivery of superior web-based core systems to the property and casualty insurance industry. Marcus’ responsibilities for Guidewire include product strategy, corporate development, and product marketing; he also serves on Guidewire’s board of directors. Before co-founding Guidewire in 2001, he was Vice President of Strategy for Ariba, Inc., an enterprise software and consulting firm providing procurement and spend management solutions. Prior to Ariba, he was an Engagement Manager at McKinsey and Company. Marcus has an A.B. from Princeton University, and a B. Phil from New College, Oxford University.