The Agile Executive

Making Agile Work

Posts Tagged ‘eCommerce

The Real Cost of One Trillion Dollars in IT Debt: Part I – Value Generation and Recapture

with 2 comments

In a recent research note and a corresponding press release, Gartner’s Andrew Kyte assessed the current level of world-wide IT Debt [1] at about $500 billion. Andrew actually considers $500 billion a conservative estimate, expecting it to grow to $1 trillion by 2015. As was pointed out by David Nagel, $1 trillion is more than four times total worldwide enterprise software expenditures this year.

I am publishing two posts in order to put these staggering figures in perspective. This post primarily addresses the business design ramifications of the numbers quoted above. A follow-on post in the coming week will explore the dire repercussions of disregarding the proven practice “an ounce of prevention is worth a pound of cure.” It will also offer an explanation rooted in our business context why this tried and true wisdom has so often been disregarded over the past decade.

The first thing to point out about the Kyte/Gartner figures is that these figures are the cost of fixing, not the value that could be lost due to the myriad malfunctions that a $1 trillion worth of software quality deficits can cause. It is like the loss incurred through fixing the truck in Figure 1 below. The cost of fixing might be $10,000. The corresponding loss of value due to the time it took to carry out the fixing of the truck is vividly captured in the quip written on the back of the sleeper: “Day late $100,000 short.”

Figure 1: “Day late $100,000 short”

Source: http://www.flickr.com/photos/bachir/489090063/

If you accept this premise, one real risk of a high level of IT debt is the deterioration of services provided through the software. An even bigger risk, however, is obsolescence of business designs due to the software systems decaying to the point that adding critical services is next to impossible. For example, consider the following B2B eCommerce services for retailers (taken from an unrelated exchange I recently had with my friend Erik Huddleston):

  • Vendor drop ship
  • Catalog/data sync
  • Vendor management
  • Compliance

It is unlikely a 10-year-old eCommerce software system whose upkeep was neglected for the past decade would have enough changeability left in it to enable providing such services. Lacking these services, the business is likely to revert to outdated designs for generating and recapturing value.

The B2B eCommerce situation discussed above is not really different from the classical dynamics of regression in the development of a child. It is, of course, poignant when a child suffers during one phase or another in his/her development. The bigger poignancy, however, is that the struggling child gets stuck. He/she is unable to move on to the next developmental phase(s). Other children surpass him/her.

What it means in less metaphorical terms is that  an incumbent with a significant IT debt might fall behind new entrants who are not (yet?) saddled with such debt. The new entrants can utilize the flexibility of their software to satisfy customer needs in ways that the incumbent’s legacy software will be hard pressed to meet. Moreover, the new entrants can modify their software in response to actual customer feedback in a much faster manner than the ‘neglectful incumbent’ can.

As an incumbent, you need to really start worrying about your IT debt if you accept the inevitability of the transformation driven by the confluence of Cloud, Mobile and Social (see Consumerization of Enterprise Software). No matter what industry you are in, the versatility, modularity, flexibility and mobility of the forthcoming consumerized enterprise software apply to every aspect of your business design. The IT debt you did not ‘pay back’ stands in the way of modernizing your business design.

Footnotes:

[1] Kyte/Gartner define IT Debt as “the costs for bringing all the elements [i.e. business applications] in the [IT] portfolio up to a reasonable standard of engineering integrity, or replace them.” In essence, IT Debt differs from the definition of Technical Debt used in The Agile Executive in that it accounts for the possible costs associated with replacing an application. For example, the technical debt calculated through doing code analysis on a certain application might amount to $500K. In contrast, the cost of replacement might be $250K, $1M or some other figure that is not necessarily related to intrinsic quality defects in the current code base.

A Devops Case Study

leave a comment »

An outline of my forthcoming Agile 2010 workshop was given in the post “A Recipe for Handling Cultural Conflicts in Devops and Beyond” earlier this week. Here is the case study around which the workshop is structured:

NotHere, Inc. Case Study

NotHere, Inc. is a $500M company based in Jerusalem, Israel. The company developed an eCommerce platform for small to medium retailers. Through a combination of this platform and its hosting data center, NotHere provides online store fronts, shopping carts, order processing, inventory, billing and marketing services to tens of thousands of retailers in a broad spectrum of verticals. For these retailers, NotHere is a one-stop “shopping” for all their online needs. In particular, instead of partnering with multiple companies like Amazon, Ebay, PayPal and Shopzilla, a retailer merely needs to partner with NotHere (who partners with these four companies and many others).

The small to medium retailers that use the good services of NotHere are critically dependent on the availability of its data center. For all practical purposes retailers are (temporarily) dead when the NotHere data center is not available. In recognition of the criticality of this aspect of its IT operations, NotHere invested a lot of effort in maturing its ITIL[i] processes. Its IT department successfully implements the ITIL service support and service delivery functions depicted in the figure below. From an operational perspective, an overall availability level of four nines is consistently attained. The company advertises this availability level as a major market differentiator.

In response to the accelerating pace in its marketplace, NotHere has been quite aggressive and successful in transitioning to Agile in product management, dev and test. Code quality, productivity and time-to-producing-code have been much improved over the past couple of years. The company measures those three metrics (quality, productivity, time-to-producing-code) regularly. The metrics feed into whole-hearted continuous improvement programs in product management, dev and test. They also serve as major components in evaluating the performance of the CTO and of the EVP of marketing.

NotHere has recently been struggling to reconcile velocity in development with availability in IT operations. Numerous attempts to turn speedy code development into fast service delivery have not been successful on two accounts:

  • Technical:  Early attempts to turn Continuous Integration into Continuous Deployment created numerous “hiccups” in both availability and audit.
  • Cultural: Dev is a competence culture; ops is a control culture.

A lot of tension has arisen between dev and ops as a result of the cultural differences compounding the technical differences. The situation deteriorated big time when the “lagging behind” picture below leaked from dev circles to ops.

The CEO of the company is of the opinion NotHere must reach the stage of Delivery over Development. She is not too interested in departmental metrics like the time it takes to develop code or the time it takes to deploy it. From her perspective, overall time-to-delivery (of service to the retailers) is the only meaningful business metric.

To accomplish Delivery over Development, the CEO launched a “Making Cats Work with Dogs[ii]” project. She gave the picture above to the CTO and CIO, making it crystal clear that the picture represents the end-point with respect to the relationship she expects the two of them and their departments to reach. Specifically, the CEO asked the CTO and the CIO to convene their staffs so that each department will:

  • Document its Outmodel (in the sense explored in the “How We Do Things Around Here In Order to Succeed” workshop) of the other department.
  • Compile a list of requirements it would like to put on the other group “to get its act together.”

The CEO also indicated she will convene and chair a meeting between the two departments. In this meeting she would like each department to present its two deliverables (world view of the other department & and the requirements to be put on it) and listen carefully to reflections and reactions from the other department. She expects the meeting will be the first step toward a mutual agreement between the two departments how to speed up overall service delivery.


[i] “Information Technology Infrastructure library – a set of concepts and practices for Information Technology Services Management (ITSM), Information Technology (IT) development and IT operations” [Wikipedia].

[ii] I am indebted to Patrick DeBois for suggesting this title.

© Copyright 2010 Israel Gat