News: 1596702607

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

UK insurance biz Direct Line drops 'misrepresentation' claims against IBM in £36m database platform lawsuit

(2020/08/06)


Direct Line has dropped its claims that IBM negligently misrepresented its ability to develop an insurance platform – though the UK insurer is continuing its £36m legal battle against the US tech giant for allegedly having "seriously underestimated the complexity" of a 2014 contract.

In a case similar to one brought against Big Blue by Co-Op Insurance [1]that was heard earlier this year , Direct Line claims IBM caused it to waste a total of £36m buying a business-critical insurance software platform that was so bad it had to be abandoned and the work redone from scratch by others.

High Court filings from the end of July show that Direct Line has abandoned its claims that IBM made a series of "negligent misrepresentations" of its ability to complete "Project Emerald", and is instead now concentrating on a single claim for breach of contract.

In the middle of the last decade, Direct Line wanted a new insurance platform built on top of Teradata's Database 14 and Financial Services Logical Data Model (FSLDM) products. It picked IBM to do this, signing a contract in December 2013 which said the resulting platform was to go live in September 2016.

Part of the contract included integrating the new platform with data warehouses and porting existing data onto it. By September 2014, Direct Line had taken some work away from Big Blue because "it had become apparent that IBM had seriously underestimated the complexity of the data translation between Guidewire version 8 and the EDW [Enterprise Data Warehouse] and therefore the ETL [Extract, Transform and Load] code that would need to be developed to affect those data translations".

Things got worse when IBM delivered a test product in June 2015, Direct Line told Mrs Justice O'Farrell. The insurer carried out "a trial bulk upload of an updated data extract" into the EDW using the IBM-built framework. "The performance of that process was impractically slow, it being estimated that it would take several elapsed [sic] months for the data load to complete," Direct Line complained.

Narked by this, the insurer demanded IBM fix the defective software at its own cost – and allegedly withheld contract payments from IBM. It also commissioned consultants from Bluesmith Information Systems Ltd to figure out why IBM's software was defective. Among other things Bluesmith found, as the High Court was told:

An exception logging route "logged issues to a single exception table", which routinely "caused a performance bottleneck"

IBM devs had "implemented a number of inappropriate primary indexes" for the Teradata database "which led to a skewed, rather than an even, distribution of data across the Teradata Access Module Processors"

Some SQL statements "made inappropriate or excessive use of compound keys, union statements, and column operations on one side of a 'join' or 'where' clause"

IBM "inappropriately made use of Open Database Connectivity for interactions with Teradata" as well as failing to "properly observe Teradata database table design standards"

Teradata itself was also brought in by Direct Line, in February 2015, to figure out why IBM's EDW was suffering "significant issues". It was said to have found a range of problems: the EDW "had been designed for load performance rather than access", which meant "performance would degrade as data volumes increased" with resulting time delays between loading the core and access layers causing "discrepancies in the results" shown to different users.

When confronted, IBM allegedly assured Direct Line that Teradata was wrong. A further Teradata report in November of that year "identified numerous serious issues and defects" including ones originally spotted back in February. Direct Line said: "The issues identified with IBM's ETL framework and EDW significantly compromised the delivery of other aspects of the data workstream."

By March 2016 the insurer lost its patience and kicked IBM off the project, only to discover that "the extent and severity of the inadequacies in IBM's work" meant its 2016 go-live date would have to be abandoned. After a tendering exercise that finished in late 2017, four new suppliers were invited to reuse IBM's previous work; they all allegedly said it would be "uneconomic" to do so.

And in our defence…

IBM countersued Direct Line for £1.1m, claiming that the insurer "had no right to withhold payment of fees" for work done by IBM. Big Blue claims Direct Line did not give it detailed notice in writing "prior to the due date of payment" that it wasn't going to pay for £600,000 of IBM's work. IBM also claims it carried out £300,000 of unpaid work after being kicked off the project by Direct Line, contributing to the £1.1m total.

The US tech firm denied having any responsibility for "the full testing lifecycle" of the platform, saying that was Direct Line's job. It also denied "that Good Industry Practice required IBM to seek to optimise its design for performance prior to the performance testing phases, particularly in circumstances where [Direct Line] had not yet defined the full set of data access requirements with the result that IBM did not have any means of knowing what needed to be optimised."

Direct Line claimed that it wasted £10.3m on failed remediation works by IBM and a further £6.6m with third parties, contributing to a total of £36m on the whole of Project Emerald.

The case, before High Court judge Mrs Justice O'Farrell, continues. Direct Line's response to IBM's counterclaim is due in late September. ®

Get our [2]Tech Resources



[1] https://www.theregister.com/2020/03/23/coop-insurance-ceo-ibm-1insurer-platform-terrible/

[2] https://whitepapers.theregister.com/

One born every..

billat29

I can stand up in front of my prospect and say, with absolute truth that my company has done something very much like what you are trying to do. I can demonstrate that we have people with the necessary skills and I will parade them in front of you.

You will sign on the foolish presumption that any of those technical titans will go anywhere near your project. In fact they will be working on more valuable accounts and helping me make the next sale.

You will just get the people that are available at the time and they are available because...

Re: One born every..

Zippy´s Sausage Factory

That actually happened to me on a project. We put in the tender that they would guarantee the people working on the project would be the ones we met in the pitch. When reminded of that, they suddenly turned very evasive...

They didn't get it. Bullet dodged, I think.

Optimising

cbars

You *never* know the full requirements up front, but that doesn't mean a full table scan or union in a join cant be designed out. That article is a litany of pure incompetence.

The position that they shouldn't have any responsibility for performance prior to official testing is a joke! The tests are there to confirm its fine, not provide requirements, its too late at that point!

Imagine having to tell your plumber the exact angles of all the pipes you want him to connect, and specify you do in fact want water to come out so a 1mm diameter won't be enough....

Mealy mouthed bastards

One wonders if

Neil Barnes

you can get something like business interruption insurance, or consequential loss insurance, against such happenings.

I suppose this means my car premiums are going up ☹

Joe Harrison

As per title

Direct Line didn’t do their side of the work

Anonymous Coward

(Posted anon as I know some of the folks involved).

As Direct Line never bothered to produce specs for what data was to be mapped where, and what they expected the system to do for them, then the import process generated huge log files reporting data it couldn’t map.

That was the reason it was slow.

Re: Direct Line didn’t do their side of the work

Warm Braw

It's hardly unusual that prospective clients don't have exhaustive documentation for their existing systems. It's always wise to sanity check the brief at an early point in the development - for example by processing a representative sample of existing data to check its conformity and ensuring you schedule your coding so this is possible. Whether it's legally necessary, the court will decide, but if you get to a position in which you've spent a fortune on development effort but find you can't actually process your client's data, noone is going to come out smelling of roses.

Project management failure

Pascal Monett

It seems obvious to me that this is not really a coding issue, this is a project management issue.

Client is complaining about some things where the supplier is saying they weren't at that stage yet. IBM use to have very competent project managers - I guess IBM has lightened its payroll a bit too much. That being said, IBM does have experience in managing projects, I'm not so sure the client does.

In any case, this is one more project that got out of hand because somebody wasn't doing his job managing the various aspects of the project.

It's even possible that it happened on both sides.

Genius doesn't work on an assembly line basis. You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3