Feature story:
Core Processing Systems: Why to Buy?
When it comes to the “build vs. buy?question, carriers shouldn’t think twice.
Jeffrey Glazer

As hardware, software, and programming languages evolve; as the e-business applications they enable become more prevalent, sophisticated, and necessary; and as the roles, sizes, and capabilities of internal IT departments continue to vary, an old debate is given new life: To build or to buy?
That is the question. Its answer remains elusive, but budgetary resources and economic realities often make the debate academic.

There are no doubt some significant advantages to build-it-yourself software and systems. For one, you have absolute control over their capabilities—at least within the bounds of your staff’s expertise. You can decide to stick with standards, or build completely customized applications.  

You can determine the interface, getting input from any departments that use it, without worrying about racking up consulting time. Should needs change, you can revisit those interfaces, again without direct cost to you. (Although you will need to have a feel for the man-hours needed by your staff; there can be a significant cost even to in-house projects.)  

With an in-house project—at least one that’s well documented—your staff will be intimately familiar with its workings, much like a mechanic who has built an engine from scratch. Idiosyncrasies in the system will be easy to correct or work around, and few surprises will lurk. Maintenance will be easier, and at least in theory, less costly. Maintenance contracts will be nonexistent. Connecting to other computers, inside or outside the company, will be easier as your staff knows its systems that well.

So, yes, there are a number of advantages to building over buying. But the scale remains tilted the other way.

Who’s On First?

Managers of the e-business component of an enterprise must cope with rapid technological change, corporate experimentation, modifications to existing products and services, pressure to deliver new products, supply-chain support, diverse Web applications, multiple distribution channels, and varied sources of input. They’re required to juggle priorities, deadlines, regulatory requirements, and system specifications. They have to answer to their bosses, their bosses?bosses, their customers, their direct reports, and their shareholders. And they frequently have responsibility for functions within the company other than e-commerce.

Who are these guys anyway?

Because organizational structures differ from company to company—with no standardization along presumable lines such as number of employees, premium volume, lines sold, etc.—there’s no way to know whether business people (CEOs, CFOs, et al.) are calling the shots, or if IT people (CIOs or CTOs) might be in charge. Given that, it’s equally impossible to know at first blush whether a company is likely to favor buying or building its next system replacement or upgrade. That’s one of the things that makes the insurance industry particularly charming, especially to systems or software vendors. But there are some signals to be read.

What’s On Second?

In the commercial property/casualty market, the debate takes a particularly sharp focus. In point of fact—or as a matter of numerical probability—it’s simply not possible for the number of insurance technology players on the field to continue making the cut. As it has on the carrier and agency sides of the business, the technology market ultimately will consolidate in the way that makes the most economic sense, long term.

Given the evolution of technology in general, and insurance processing systems in particular, the “build vs. buy?debate will heat up, even as it gets closer to resolution. But given the baseline needs every system must fulfill—and the challenge internal IT departments face in keeping pace with change—it’s likely that long-term thinkers and foresightful insurers will choose to buy the majority of the functionality required by their systems.

Here’s why:

Speed. In any business, you’re only as competitive as your last move. In the insurance business, it’s the first moves that provide the greatest advantages. Speed to market is crucial, as is the speed with which change is accommodated, service is delivered, customer needs are met, information is managed, and transactions are processed.

The need for speed becomes more crucial in the context of e-business. As things move and change quickly on the Internet, products, services, and delivery methods must be able to adapt just as quickly. If the average Web surfer will wait eight seconds for a page to download, how long do you think your customers will wait for a credit report or a comparative rate, especially if your competitor delivers in real time?\

Complexity. E-business increases complexity and makes your entire system more vulnerable to performance problems. You might be running a hyperlinked application and accessing countless files, all of which are linked to unknown external sites and channeled through a changing array of Web servers.

All that functionality and data must connect with your internal systems, which probably comprise a patchwork of packaged applications and legacy technologies. For this hodge-podge to work, your system has to provide not just information but self-service capabilities, workflow processes, and integrated application interfaces.

Scalability. Core business systems must be able to accommodate growing lines of products and services. They also must have the capacity to incorporate the growing demands of customers and corporate management. Because the demands of users on the Web are difficult to anticipate or control, they become another level of complication from e-business. If your applications are called to handle sudden and sporadic surges of activity, the importance of scalability increases commensurately.

Back-end Functionality. Ultimately, the speed of your system, the level of complexity it manages, and its scalability come down to the functionality of your back end. To illustrate the extent to which e-business is, indeed, a complicating factor, consider this: 

Let’s say an insurance carrier’s system presently has some number of internal users, which may include employees of the carrier, as well as agents and brokers who are connected to the system through a proprietary interface. Assume those users generate some other number of transactions against your processing system, and assume that with that volume of transactions, you get a performance issue on the average of once an hour—a functional problem that results in downtime for at least one of your users and maintenance time for someone else who has to fix the problem.

Now let’s say you integrate your processing system with Web applications that provide access to greater numbers of users who no longer are required to use your proprietary interface. If your back end isn’t equipped to manage that kind of a spike in input volume and output demand, you’ll be facing significantly more performance problems, down-time, and maintenance costs. Instead of averaging your performance issues, you may be averaging how many minutes every hour your system is online, if it doesn’t crash completely. And there’s one more thing: That database you routinely took offline for backup, recovery, or general maintenance now lives in a 24/7 world.

Welcome to e-business.

I’m Not Asking You Who’s On Second. Who’s On First.
I Don’t Know!  Oh, He’s On Third.

To make sure their business needs are covered adequately, managers of insurance enterprise systems and e-business must accommodate industry change, product and service delivery, information management, supply-chain support, multiple distribution channels, and ever-shifting technologies. They need to be able to assess their human resources, project their budgets, and anticipate their requirements. And they need to make the decision—or influence the decision—whether to build or to buy.

As this scenario plays out, the smart money will be buying. IT managers will be fulfilling their responsibility for ensuring efficient workflows, sufficient capacity, and competitive functionality—and outsourcing the responsibility for implementation, maintenance, and compliance. Rather than attempting to compel internal IT resources to keep pace with new technologies, design and configure software, integrate applications across the enterprise, and perform ongoing maintenance, IT managers will be looking to lower their cost of application integration (i.e., get it right the first time), minimize implementation time (e.g., employ technologies someone else has borne the cost of proving), maximize their legacy investments (e.g., use existing applications for new purposes), and end up with an infrastructure that supports e-commerce, supply chain management, customer relationship management, and other programs (i.e., ensure scalability through foresight).

Because most IT managers can get 80 to 90 percent of the capabilities they need out of the box from a packaged system—and because any dog with a byte will customize integration, if not applications, and sell the system incrementally in modules—build vs. buy won’t be a debate for long.