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 capabilitiesat least within the bounds of your staffs 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 projectat least one thats well documentedyour 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.

Whos 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. Theyre 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 companywith no standardization along presumable lines such as number of employees, premium volume, lines sold, etc.theres 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, its equally impossible to know at first blush whether a company is likely to favor buying or building its next system replacement or upgrade. Thats 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.

Whats On Second?

In the commercial property/casualty market, the debate takes a particularly sharp focus. In point of factor as a matter of numerical probabilityits 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 fulfilland the challenge internal IT departments face in keeping pace with changeits likely that long-term thinkers and foresightful insurers will choose to buy the majority of the functionality required by their systems.

Heres why:

Speed. In any business, youre only as competitive as your last move. In the insurance business, its 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:

Lets say an insurance carriers 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 houra 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 lets 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 isnt equipped to manage that kind of a spike in input volume and output demand, youll 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 doesnt crash completely. And theres 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.

Im Not Asking You Whos On Second. Whos On First.

I Dont Know! Oh, Hes 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 decisionor influence the decisionwhether 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 functionalityand 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 systemand because any dog with a byte will customize integration, if not applications, and sell the system incrementally in modulesbuild vs. buy wont be a debate for long.

Jeffrey Glazer is executive vice president for Insurity (www.insurity.com). Tony Reisz is Insuritys director of sales.

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

  • Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
  • Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
  • Educational webcasts, white papers, and ebooks from industry thought leaders
  • Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor
NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.