Sponsor

Saturday, November 21, 2009

Technology Debt?

Technology debt is real - and yes it has to be paid back. The challenge is 'how can the industry standardize or formulate a measure of Technology debt. Technology Debt encompasses the cost to the business, impacting new systems as well as the operational costs for existing systems.

3ys1atex

An example – An insurance company decides to venture into a new market based on tremendous potential and little competitor penetration. Time to market will clearly be a factor for delivery; budget tends to be hard to come by and the ROI models are tied to the annual shareholder objectives.  So the typical requirement to IT is to deliver all features within a specific timeframe at $ budget.

Common IT wisdom dictates that this is an impossible task.  MSF for example specifies that one of the constraints can be prime while the remaining two have to adjust.  Quality is assumed to be constant.

In the enterprise context, I would consider this to be an every day request/occurrence, which is NOT dysfunctional but which should be embraced given a proper framework for tracking the impact of this approach.

What I believe needs to be constant is (business) effectiveness. 

Quality and Risk Trade-offs:

  • Design
  • Architecture
  • Vendors
  • Defects per k
  • Operational Cost

There a multiple benefits:

  • Business Agility.
  • Delivering impactful business systems at lower initial cost.

Obviously the pendulum swings the other way once the market has been effectively served;  the battle for market share now tends to be prolonged and in small increments.  The push for efficiency now becomes important.

An organization that has tracked Technology Debt will have planned for the shift and can now appropriately communicate to Shareholders/Employees etc. why investment has to be made into systems.

Theoretically 'the perfect system' can be built eventually.
The perfect system never breaks and provides 100% business value 24/7 and the cost to create and operate never exceeds its value.

All prior generation systems attempt to meet the perfect system standard, trade offs define the actual system.

Ergo, the difference between the perfect system and the delivered system(s) is the Debt.
The future of Enterprise Architecture is now?

Martin Fowler’s perspective on Technology Debt - http://martinfowler.com/bliki/EstimatedInterest.html

To measure and apply technology debt, several dimensions would have to be taken into consideration, but I do think that the merits of tracking it would outweigh the costs. 

No comments: