by Ian Rowlands
I’ve been thinking recently about how we address the paradox that no matter how low the cost of storage declines, the costs of information capture, access and management keep on growing. Not surprisingly, business leaders are asking IT leaders “are we getting full value for our information investment?” What came to mind was that many clever people have done much good work on managing various aspects of the IT portfolio, but not so many (if any) have given the same thought to the “data portfolio”. It seems like there is a nasty tendency to regard data as a byproduct of business processes and applications when it comes to considering the balance between data cost and data value.
One concept that looks to me as though it may be worth exploring is the notion of “Technical Debt”, first articulated by Ward Cunningham as long ago as 1992. In the applications space, the idea is that development organizations take decisions about applications that defer future costs in favor of current benefits. For example, there may be a decision to add a feature to an existing application without spending time considering all the potential impacts, to get to production faster. There is a future cost – but the time-to-market benefit may make the trade-off acceptable.
Organizations can incur technical debt deliberately or accidentally (a bug might be considered unintentionally acquired debt). I think I see a Data Management analog – “Data Debt”. You might incur Data Debt, for example, by creating multiple instantiations of the same data entity, with different representations. This kind of duplication is the source of the mother and father of all Troubled Asset (Debt) Relief Programs – Debt TARP, which we call Master Data Management!
Failing to archive data that is no longer in use also incurs Data Debt. That ought really to bother you … It would mean that the business is using resources to service an asset that is no longer providing value. There is a potential security issue as nobody takes care of data that nobody is using.
I can only scratch the surface of data debt in a blog. Data Debt is only one aspect of Data Portfolio Management. Data Portfolio Management, in turn, is only one aspect of Data Governance. That’s good for me, because it means there’s plenty more for me to write about!
What should you do about it? Categorize data assets so you can rationally allocate costs and values — by customer group, line of business, application. Categorize by technology as well. Work to understand the costs of maintaining data assets, and the business value supported. Understand the risks of technology obsolescence. With some key metrics in hand, start making intentional decisions about managing data debt. It will pay dividends! The IT organization that represents data as a corporate asset and demonstrates proactive management in line with enterprise goals will be best placed to answer the “value for money” question.