Data warehouses fail precisely because they are conceived andbuilt as data warehouses.

Trade places with the CFO of your insurance company. Now you'restruggling with a loss ratio of 105 percent and can't get a handleon the underlying reasons. A software vendor pops in to see you,suggesting he can help. His sales pitch: He'll build you a nicething called a "data warehouse" that will store the data from whichyou can easily "mine" information. Curious, you agree to a meetingand the dialogue soon begins.

Unfortunately, a roadblock appears. You quickly start to believethat you have been kidnapped and are now on an alien planet. Thelanguage doesn't seem to be in English, or at least notinsurance-speak (remember, you're the CFO here). You hear words andphrases like: "ODBC," "multi-dimensional," "RDBMS," "bit-mappedindices," "object-oriented design," "extendable," "scalable,""pre-packed data models," and the kicker, "enterprise-wide datawarehouse." That's it. For $2 million to $4 million and 18 to 24months, the answer is an enterprise-wide data warehouse.

Or is it?

Wouldn't you rather have heard about a three- to six-monthproject to empower your actuaries to drill down into such depththat they would be able to surgically price products to improve thebottom line? Or how about providing your claims analysts withenough detailed information to be able to quickly reduce claimseverity? That's solving your insurance business problems-and it'snot a technology odyssey.

Feel Their Pain

In our quest to solve real problems, we've somehow flip-floppedthe business and technical drivers. As a collectiveindustry-vendors, internal IT, and consultants-we are guilty offocusing too much on the underlying technology and not enough onthe real pain-points of the business executives.

That doesn't mean we should ignore the equipment or the need tohave a solid technology foundation. On the contrary, it's importantthat the various infrastructure layers within a solution arerobust, scalable, and open, but if the pain-point isn'tsolved-really solved-the project is a failure.

In our example, if the CFO could see a drop in the overall lossratio on a book of $50 million business from 105 percent down to100 percent, that would be a $2.5 million increase to the bottomline. Not a bad ROI. This project would obviously be a success withmany promotions and performance bonuses distributed.
Here's my list of a few key insurance challenges and pain-points tofocus on:

- Improve profitability
- Improve forecasting
- Improve underwriting criteria
- Reduce claim severity
- Surgically improve pricing
- Improve loss control programs
- Improve reserve analysis
- Streamline reconciliation
- Target marketing and sales on profitable business
- Optimize distribution channels

Now, about that underlying technology: Think back to "Raiders ofthe Lost Ark"-that wonderful flick that captured our hearts back in1981. Do you remember the ending? The ark wasn't lost; it was inthe process of being stored in an enormous government warehouse. Itwas safe and sound, dutifully cataloged.

The imagery was clear: This was a priceless artifact that wasprobably never going to be retrieved again.
The lesson from the movie, at least on the technology side, is thatyou need to have a way of getting the data into the warehouse, anexcellent multi-dimensional design layer, a fast database engine,business rules to process the information, and aninterface/visualization layer that allows those forklifts toquickly grab that historical artifact with ease.

Extract, Transform, Load. Moving data fromlegacy and operational systems into an analytic system is usually astraightforward process. The challenge lies within the dataquality. Quite often annoying items-is "John Smith" the same personas "J Smith"?- create their own challenges. Several vendors offerfairly sophisticated tools to assist in developing repeatable,more-easily-maintained processes.

Analytic Data Infrastructure. An oftenmisunderstood and neglected component is thedata-infrastructure-design layer, which serves as the foundation tosupport the analytic solution. With an effective design, the rightinformation is collected and organized so that it can beefficiently used. The design should also support future expansionsand customizations of the analytic functionality without thecarrier having to embark upon a major redesign effort.

The two most critical features of this layer are that it mustsupport unlimited dimensions and measures, and lowest level ofdetail data.

The more ratings measures that can be analyzed-coupled with theability to "slice and dice" via every dimension stored-provides apowerful capability to get at the root of exactly, for example,where the profitable and unprofitable business is hiding. Summarydata are useful for surface, exterior, and level analyses; to fullyunderstand and transform the information into actionable knowledge,you need to use detail-level data.
Informational Database Engine. One major differentiation betweentransactional and informational systems is the unpredictable natureof analytic systems. Being able to support large volumes of dataaccess without knowing precisely which data elements the end userswill want to slice and dice is challenging. The poor databaseadministrators often are in a no-win spiral of constantly being astep behind the power users.

Supporting volumes of more than $50 million policies is notunusual.

The lesson? Carefully evaluate which database engines cansupport your needs with today's known requirements, and those thatcan handle tomorrow's demands.

Insurance Business Rules, Measures, andDimensions. In an industry with such complex businessrequirements, it's amazing how many solutions are generic. Thislayer provides the real insurance intellectual property that givessignificant productivity gains and value to the business analystsand users.

Visualization Layer. This layer is usuallyassociated with the "sizzle" and is the layer with which actuarial,claims, marketing, and financial analysts and power users interfaceon a regular basis. Of course, some people like to crunch throughspreadsheets, and some like to read text-based reports. Others wantto see beautiful 3-D graphics. The visualization layer musteffectively support all of these diverse user preferences. Inaddition, it must support the ability to slice and dice through thedata on an ad hoc basis in order to identify the underlying trendsand relationships.

With any big tech implementation, people, attitudes, skills, andbeliefs travel hand-in-hand with software and hardwarefunctionalities. If one side fails, everything will crumble. (Nopressure.) But if done right, someone might suggest that you'vesuccessfully delivered a data warehouse.

Paul Theriault ([email protected]) issenior vice president for marketing and channels at PinpointSolutions.

Executive buy-in is as crucial to your datawarehouse as the technology you use.

by Ben P. Rosenfield

Once you've worked through the ins and outs of what you need toget a data warehouse up and running, it's time to convince thebrass. Bottom lines, ROI, and other financials influence the wayexecutives think-especially if they're technophobes. The topexecutives are the most critical people involved with the success(or failure) of the project. Their sponsorship of, and commitmentto the warehouse initiative will guarantee it will be apan-organizational tool.

Getting the big cheese to melt over your idea and open the fundfloodgates can be tough. Let's face it; no one wants to pitch aproject that could face a fluctuating ROI. But it's a key issuethat can't be avoided, according to Phil Bucci, managing partner ofNCR division Teradata's professional services (www.teradata.com).

"Early success that delivers value is key to the future of thewarehouse," he said. "Look at needs across the organization, makeROI calculations based on business objectives, and focus onobjectives with high ROI."
If you can, identify something-anything-meaningful in the projectthat will indicate the warehouse's potential to pay for itself. Byconvincing the execs that they're funding a pay-as-you-goimplementation-not a broad infrastructure-you'll further guaranteesuccess.

If you're able to get past the first round of convincing,concentrate next on winning employees over. After all, you're notadding more RAM to their desktop PCs; corporate culture is about tochange. Failure comes in so many flavors. Implementing a warehousethe employees don't understand-or hate blindly-will leave you withDilbert cartoons slipped anonymously under your door.

Keep Your Friends Close

First, accept the fact that culture will shift. A new way tostore, access, and share data across the organization is takingshape, so assess thoroughly what changes are likely to occur aroundthe office and the company overall. Next, find the gaps and fillthem with new or revised skill sets for IT people, or hire some newblood such as statistical modelers to add and maintain newfunctions. Finally, demonstrate to the workers how the new systemwill make their lives easier. They'll certainly do cartwheels overbeing able to access data and functionality as never before.

But don't worry about the people so much that you neglect theproduct. Company-wide acceptance of the warehouse could turn aroundand bite you in the ass. Too often, according to Bucci, lack ofexperience leads warehouse project managers to focus design specsand efforts on initial implementation, leaving near-future needsblowing in the wind.

"Once initial implementation is done successfully, theunderestimated demand-the rush of users to get more information-cancause the system to fail," Bucci explained. "Ease of expansion willalleviate the burden created by unanticipated needs."

By creating a system with big britches, you will further lock inemployee support for the warehouse. They'll believe the system wasdesigned with their needs in mind, and they'll be thrilled to useit. In turn, the higher-ups will be happy.

But this is all philosophical, really. Pleasing the masses is adynamic struggle; pleasing the machinery, on the other hand-makingsure it has the muscle to carry the workload-is much morestraightforward. The software makes the hardware work. Disks won'tspin until told to. You need to invest in data warehouse softwarewith the potential for scalability, TCO (total cost of ownership)restraint, and end-to-end parallelism.

If your system is scalable, you'll be able to start small anddevelop a logical business model-and then make the model evident inyour database. In turn, you'll be able to query the database inphases based on specific subject areas. In time, adding newquestions to the system will be no problem because you implementedtechnology that grows with you.

TCO, on the other hand, prevents certain types of growth. Howmuch does it cost to own your data warehouse? The figure includesmanpower, workloads, overtime, and more. What support is absolutelynecessary for the environment you chose? If you keep your mind onthese concepts, you should be able to keep the leash on yourTCO.

"Think about how many database administrators are needed," saidThomas Grimm, partner in Teradata's professional services solutionarchitecture group. "If you need one for each mainframe, and onefor each data mart, that's a ton of support."

Grimm explained that the more the database manages itself, thebetter. Normally, more human-dependent systems that needrearranging based on new questions require people to back data outonto tape, repartition the hard drives, and then reload the datafrom tape. That can be an exhausting, weekend-long project, and canquickly burn the best workers out.

"If you have databases that deal with terabytes [of data] andthere are humans involved, it's a major TCO issue," Grimm said."You also run the risk of losing valuable staff by attrition."

Human involvement is costly-especially when those pesky humansmake mistakes. According to Grimm, total absence of humanintervention in the database fosters the best environment for datasharing across an organization. End-to-end parallelism is theoperative phrase. It means data are taken, split evenly, and servedthat way to everyone. As Grimm put it, the process is an "even,random distribution of data, managed by the database." In thisscenario, all data and tasks are executed in parallel distributionsacross the enterprise.

It's all about openness. Is your software flexible enough tohandle your changing and growing needs? Can it do so without toomany people butting in? And can it employ emerging standards fordata sharing? While focusing on essential software attributes, keepin mind solving real pain-points quickly and completely. Onceyou've done that and have the right solutions in place, seniorexecutives will be impressed with the results.