Posts Tagged ‘Compliance’
The Real Cost of One Trillion Dollars in IT Debt: Part I – Value Generation and Recapture
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.
The Devops Triangle
The Agile Triangles was introduced by Jim Highsmith as an antidote to the Iron Triangle. Instead of balancing development between cost, schedule and scope, the Agile Triangle strives to strike a balance between value, quality and constraints:
Figure 1 – The Agile Triangle (based on Figure 1-3 in Agile Project Management: Creating Innovative Products.)
Consider the Iron Triangle in the context of devops. Value, quality and constraints apply to IT operations as meaningfully as they apply to software development. IT can go beyond cost, schedule and scope to focus on value and quality just as the Agile software development team does. Between development and operations the specific tasks to be carried out change, but the principles embodies in the triangle remain invariant.
In addition to cost, schedule and scope, devops projects must cope with another constraint: compliance. For example, a bank that implements a ‘follow the sun’ strategy with respect to trading must finish reconciling transaction that took place in London before the start of trade in Wall Street. From the bank’s point of view, its IT department needs to be mindful of four constraints: compliance, cost, schedule and scope. This view is represented in Figure 2 below.
Figure 2 – The Devops Triangle
Balancing the four constraints – compliance, cost, schedule, and scope – is not a trivial task. However, just like the Agile Triangle, the Tradeoff Matrix used in Agile software development applies to IT. In its software development variant, the Tradeoff matrix is an effective tool to decide between conflicting constraints, as follows:
Table 1 – Tradeoff Matrix (based on Table 6-1 in Agile Project Management: Creating Innovative Products.)
For devops, the matrix is extended to include a compliance row and a Reluctantly Accept column as follows:
Table 2 – Tradeoff Matrix for Devops
The Devops Triangle and the corresponding Tradeoff Matrix demonstrate how governance a la Agile can be extended to devops projects as far as compliance goes. The proposed governance framework however is incomplete in the following sense: schedule in devops projects can be a much more granular and stringent constraint than schedule in “dev only” projects. The subject of schedule constraints in devops projects will be addressed in a forthcoming post.
An Update on Agile Business Service Management
A previous post in this blog defined the demarcation line between The Agile Executive and BSM Review as follows:
If software development is your primary interest, you might find my forthcoming posts in BSM Review go a little beyond the traditional scope of software methods. If, however, you are interested in software delivery in entirety, you are likely to find good synergy between the topics I will address in BSM Review and those I will continue to bring up in The Agile Executive. Either way, I trust my posts and Cote’s will be of on-going interest to you.
Since writing these words, I realized how tricky it is to adhere to this differentiation. The difficulty lies in the “cord” between development and operations. Development needs to devise algorithms that take into account operational characteristics in IT. Operations needs to comprehend the limits of such algorithms in the context of the service level agreements and operational level agreements that had been negotiated with their customers (either external or internal). The mutual need is particularly strong in the web application/web operations domain where mutual understanding, collaborative work and joint commitment often need to transcend organizational lines.
Given the inherently close ties between development and operations, here are some BSM Review articles and posts that are likely to be of interest to readers of The Agile Executive:
- The Joys of Real Hardware – what it means to do Business Service Management on a very large-scale
- The Voice of the CIO – a study on the attributes needed by today’s CIO (yes, you had better be agile and Agile…)
- The Quest for a Maturity Model in Business Service Management – while the focus is on BSM, some of the models might apply in a fairly straightforward manner to Agile
- Business Service Management, Six Sigma and your IT Compliance Program – lessons to the champion who has one foot in Agile, the other foot in Six Sigma
- A Measured Approach to Cloud Computing – what it really means to “… make muck so you don’t have to”
- The Case for Agile Business Service Management – the fusion of modern software development methods with the prevailing preference to run IT from the perspective of the business customer
It is a little premature at this early stage to project how BSM Review will evolve. My hunch is that forthcoming articles in BSM Review on cloud computing, large-scale operations, leadership, risk mitigation and technology trends will be of particular interest to readers of this blog.
The Agile Executive 
