Several weeks ago, Knight Capital Group imploded. A technical glitch in an algorithm on one of Knight’s marketing computers caused it to mishandle 150 shares of NYSE stock.
As a direct result, the firm “lost $440 million of the firm’s capital in a trading disruption.” Its value plunged from $1.5 billion to a little over $1 billion in a single day. While the details are still a bit sketchy, the culprit appears to be a good old-fashioned a system failure.
Lamentably, I know more than most about these types of things. Call it either bad luck or just prosaic real world experience. In my years implementing enterprise systems, I've seen scenarios like Knight's play out very often, although I've never seen a firm lose one-third of its value within 24 hours.
So, while I don't know too many specifics about the Knight Capital case, allow me to offer several pieces of completely unsolicited advice. My bet: that many of these explain such a massive system failure.
Project Buy-In Starts at the Top
Throughout a project, organizations need routine involvement from functional leads, CXOs and other heads of lines of business (LOBs). Allowing certain execs to remain uninvolved throughout a project is a recipe for disaster. Senior leaders who do not hold their direct reports accountable don't exactly inspire accountability.
When implementing a new system (especially one responsible for stock trades), do not try to merely replicate the old in the new. Never mistake can, should and must. Just because functionality in both the legacy and new systems can be the same does not mean that it's a good idea.
Understand the Importance of Data Profiling and Quality
As early as possible, clean up your data. Delaying these efforts causes at least two problems. First, the cleanup effort will probably take more time. Second, it will be politically more difficult for data stewards to speak up, especially in politicized environs. (They will be the ones seen as delaying the project.)
Do not begin a major system implementation with both a tight timeline and the assumption that the data can be properly cleansed during the project. Make data cleaning a separate project before beginning the "real" project in earnest.
First, data profiling is not a luxury; it’s an investment and a requirement. The time and money spent data profiling will pay off in spades. It forces the organization to ask:
- Which data elements are essential?
- Which are not?
- Which are unclear?
- Which are lacking?
Simon Says
Data profiling and DQ should not be considered initiatives. They need to be imbued in an organization’s culture. Data quality cannot be crammed in like a new application. It's not an afterthought – or at least it shouldn't be. Executives cannot one day embrace its tenets and expect the old guard to fall into line. I'll bet that Knight lacked a refined DG program and never bothered to consider implementing one prior to activating its new trading system.
Feedback
What say you?
