London Bourse is Falling Down – Time to Analyze Its Structure?

Posted By Lev on February 25, 2011 | Industry News, Software Quality, Technical Debt

This morning’s news was rife with accounts of the London Stock Exchange Group being forced to halt trading on its main market due to a technical fault in its barely two-week-old MilleniumIT trading system.  This is yet another example of the need for pre-deployment analysis of structural quality.

An average mission critical application has just under 400,000 lines of code, 5,000 components, 1000 database tables and just under 1000 stored procedures. Architecturally, these components are layered such that an average transaction passes through about five layers between the user and the data. The applications that are in the top quartile of size and complexity comprise over 2.5 million lines of code, and though we haven’t analyzed the MilleniumIT trading system, it is probably well into the top quartile…probably well beyond that mark.

As these applications get enhanced to meet new market needs, a myriad of components are altered by hundreds of developers. Every change to every component affects interactions with many other parts of the system in many ways. There are known software engineering rules to safeguard these interactions that are often neglected either unwittingly, or willfully due to time pressure. These software flaws are measured by engineers as structural quality and quantified in dollars as technical debt. Technical debt makes development less agile because the code is more complex, riskier to modify and harder to test.

When the LSE acquired MilleniumIT in October 2009, we can assume they had very little understanding of the technical debt hidden in their new asset. It’s not their fault! Very few in the industry have yet gotten their arms around technical debt and the industry is just learning how to take it into account during M&A. But it’s very real, as we’ve seen the last couple of weeks at the LSE. Most enterprises are in the more fortunate position of being able to hide these issues a little more than the LSE, but with the many tweeters now lurking out there, that comfortable blanket is also slipping away.

The LSE trading platform, which failed again today while displaying bizarre ask/bid price behavior, was no doubt thoroughly tested before being switched on. The reason for failure was “algorithms,” but with over half of all trading today being computer-driven algorithmic trading, this is not reassuring. Today’s serious disruption demonstrates that even the most rigorous testing is not enough. When systems are this complicated, testing of known unknowns only lulls you into a state of false complacency. The LSE’s reputation and its Chief Executive’s M&A plans are now facing just a little more unwelcome scrutiny.

We have to get beyond testing, which cannot determine the structural quality of the whole system – how good is the design, how well is this design implemented, and how capable in the face of unknown unknowns.  We need to measure structural quality to capture the design and implementation “goodness” of complex systems. Our customers are doing this by analyzing their critical applications and quantifying the structural quality in terms of technical debt – the cost of fixing the structural problems that cause severe business disruption like today’s at the LSE.

Technical debt measurement gives CEOs and CFOs a clean way to value their IT systems. For most IT-intensive business today technical debt levels are too high and as an industry we need to learn to address this, before our software “bridges” go down again, in London or elsewhere.

Tags: structural quality, Technical debt