The Agile Executive

Making Agile Work

Archive for the ‘Enterprise Software’ Category

Getting Ready for Agile 2011 – Part II

leave a comment »

In her recent post Getting Ready for Agile 2011, Anne Mullaney gave an outline of my forthcoming sessions at the conference. Specifically, she highlighted the emergence of new forms of Agility:

“Super-Fresh Code” is a term Israel coined (an extension of the “Super-Fresh Web” concept) to describe code that results from seizing upon the opportunities opened by combining recent advances in Agile software methods, cloud computing, mobile applications, and social networking. With the right mix, a company can outgun, outclass and outmaneuver its competition through real-time requirements management and superior business designs. Essentially, super-fresh code becomes the source of competitive advantage. This is a workshop that will make you think about Agile in ways you never have before.

Appropriately enough for the anniversary year of the Agile Manifesto, my strong conviction indeed is that we are just about witnessing Agile going beyond being “just” a software method. Markets are becoming hyper-segmented. There is no way to reach tiny, granular market segments economically without sophisticated software. Moreover, markets are becoming ultra-fluid. It takes a high degree of software-based business agility to penetrate market segments that form and collapse at the speed with which social networking groups emerge (and disappear). Hence, software is becoming a bigger and bigger part of just about any business — avionics, financial services, healthcare, retail, transportation, telco, and so on. In fact, in many engagements Cutter consultants carry out, the software is the company. Unless Agile methods are used strategically, the ability of a company to generate value for its customers and capture profit for itself might be in jeopardy: the company simply cannot adapt fast enough in the face of a significant amount of technical debt.

Viewed from this perspective, technical debt becomes an integral part of Agile methods. One starts an enterprise level Agile roll-out in order to, well, gain Agility. The accrual of technical debt puts a damper on Agility. Hence, implementing a technical debt assessment, reduction and prevention program is an essential part of the Agile initiative. In fact, Cutter recommends to its clients to integrate the two all the way down to the backlog stories.

I can’t wait to discuss these topics with you and other Agile 2011 participants in just about two weeks!

Implications of Technical Debt Uncertainty for Software Licensing Negotiations

with 2 comments

A few years ago, my friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, open source software will steadily gain ground from traditional enterprise software vendors.

Consider this chart from a buyer’s perspective. Functionality (the vertical axis in the chart) can be thought of as value. Whatever the value might be, it is diminished by technical debt in the software as the debt manifests itself as application crashes, degradation of  performance and possible corruption of customer data. Everything else being equal, an application with lower technical debt per line of code is preferable to an application with a higher technical debt per line of code.

Traditional enterprise software vendors do not typically provide the technical debt data for the applications they sell/license. In contrast, a customer can carry out his/her assessment of technical debt straight off the open source code. For example, colleague and friend John Heintz carried out the following technical debt analysis on the Cassandra open source project:



As demonstrated in this chart, any customer can measure the level of technical debt in an open source software he/she considers. For better or worse, there is no uncertainty about the amount of technical debt the customer will need to live with in an open source software. In contrast, a customer will usually need to live with  uncertainty about the level of technical debt in proprietary software.

Uncertainty has economical consequences. For example, testing a product increases its value because it decreases operational uncertainty. The economical value of uncertainty about technical debt is conceptually depicted in the figure below in which value is adjusted in accord with the knowledge or lack thereof of the amount of technical debt. Please note that the following equation holds for the various intersection points on the Enterprise Customer Requirements line: {T3-T2} < {T1-T0}. What this equation means is that under conditions of uncertain technical debt open source software is becoming more attractive than proprietary software faster than it would without taking technical debt uncertainty into account.

Action Item: Before licensing an enterprise application or renewing an existing license, ask the vendor for technical debt data for the application and the plans to reduce the debt. If the vendor refuses to disclose this data or can’t generate it within a reasonable amount of time, ask for the number of open bugs against this application in the vendor’s bug data base. Use either kind of data to drive down the price. Consider  an open source solution (even if it provides less functionality than the proprietary software product) if the vendor you are dealing with refuses to disclose either the technical debt data or the number of open bugs in the enterprise application.

____________________________________________________________________________________________________

Negotiating a major enterprise software deal? Let me know if you would like assistance in bringing up technical debt issues with the vendor to help with negotiating the price down. Click Services for details and contact information.

____________________________________________________________________________________________________

How Technical Debt Ties to Cloud, Mobile and Social

leave a comment »

http://en.wikipedia.org/wiki/File:West_Side_Highway_collapsed_at_14th.jpg

Many years ago, when I came to the US, I was shocked to the core seeing the collapsed West Side Highway in New York City. I simply could not believe that a highway would be neglected to that extent amidst all the affluence of the city. The contrast was too much for me.

Nowadays I often have a deja vu sensation in various technical debt engagements in which I find the code crumbling. This sensation is not so much about what happened (see The Real Cost of a One Trillion Dollars in IT Debt: Part II – The Performance Paradox for an explanation of the economics of the neglect of software maintenance during the past decade), but about the company for which I do the assessment giving up on immense forthcoming opportunities.

Whether you do or do not fully subscribe to the vision of the Internet-of-Things depicted in the figure below, it is fairly safe to assume that your business in the years to come will be much more connected to the outside world than it is now. The enhanced connectivity might come through mobile applications, through social networks or through the cloud. As a matter of fact, it is quite likely to come through a confluence of the three: Cloud, Mobile and Social.

http://en.wikipedia.org/wiki/File:Internet_of_Things.png

In the context of current trends in cloud, mobile and social, your legacy software is like the West Side Highway in New York City. If you maintain it to an acceptable level, it can become the core of two major benefits of much higher connectivity and connectedness in the not-too-far future:

  • Through mobile and social your legacy software will enable you to flexibly produce, market and distribute small quantities of whatever your products might need to be in niche markets.
  • Through cloud it will enable you to offer these very same products and many others as services.

Conversely, if you consistently neglect to pay back your technical debt, your legacy code is likely to collapse due to the effects of software decay. You certainly will not be able to get it to interoperate with mobile and social networking applications, let alone offer it in the form of cloud services. Nor would you be able to wrap additional services around decaying legacy code. Take a look at the warehousing and distribution services offered by Amazon to get a sense of what this kind of additional services could do for your core business: they will enable you to transform your current business design by adding an Online-to-Offline (O2O) component to it.

What is the fine line differentiating “acceptably maintained” code from toxic code? I don’t think I have conducted a large enough sample of technical debt assessments to provide a statistically significant answer. My hunch is that the magic ceiling for software development in the US is somewhere around $10 per line of code in technical debt. As long as you are under this ceiling you could still pay back your technical debt (or a significant portion of it) in an economically viable manner. Beyond $10 per line of code the decay might prove too high to fix.

Why $10 and not $1 or $100 per line of code? It is a matter of balancing investment versus debt. An average programmer (in the US) with a $100,000 salary would probably be able to produce about 10K lines of Java code per year. The cost of a line of code under these simplistic assumptions is $10. Something is terribly wrong if the technical debt exceeds the cost per line. They call it living on margin.

Action item: CIOs should conduct a technical debt assessment on a representative sample of their legacy code. A board level discussion on the strategic implications for the company is called for if technical debt per line of code exceeds $10. The board discussion should focus on the ability of the company (or lack thereof) to participate in the business tsunami that cloud, mobile and social are likely to unleash.

____________________________________________________________________________________________________

Considering modernization of your legacy code? Let me know if you would like assistance in monetizing your technical debt, devising plans to reduce it and governing the debt reduction process. Click Services for details.

____________________________________________________________________________________________________

The Real Cost of One Trillion Dollars in IT Debt: Part II – The Performance Paradox

with 7 comments

Some of the business ramifications of the $1 trillion in IT debt have been explored in the first post of this two-part analysis. This second post focuses on “an ounce of prevention is worth a pound of cure” aspects of IT debt. In particular, it proposes an explanation why prevention was often neglected in the US over the past decade and very possibly longer. This explanation is not meant to dwell on the past. Rather, it studies the patterns of the past in order to provide guidance for what you could do and should do in the future to rein in technical debt.

The prevention vis-a-vis cure trade-off  in software was illustrated by colleague and friend Jim Highsmith in the following figure:

Figure 1: The Technical Debt Curve

As Jim astutely points out, “once on far right of curve all choices are hard.” My experience as well as those of various Cutter colleagues have shown it is actually very hard. The reason is simple: on the far right the software controls you more than you control it. The manifestations of technical debt [1] in the form of pressing customer problems in the production environment force you into a largely reactive mode of operation. This reactive mode of operation is prone to a high error injection rate – you introduce new bugs while you fix old ones. Consequently, progress is agonizingly slow and painful. It is often characterized by “never-ending” testing periods.

In Measure and Manage Your IT Debt, Gartner’s Andrew Kyte put his finger on the mechanics that lead to the accumulation of technical debt – “when budget are tight, maintenance gets cut.” While I do not doubt Andrew’s observation, it does not answer a deeper question: why would maintenance get cut in the face of the consequences depicted in Figure 1? Most CFOs and CEOs I know would get quite alarmed by Figure 1. They do not need to be experts in object-oriented programming in order to take steps to mitigate the risks associated with slipping to the far right of the curve.

I believe the deeper answer to the question “why would maintenance get cut in the face of the consequences depicted in Figure 1?” was given by John Seely Brown in his 2009 presentation The Big Shift: The Mutual Decoupling of Two Sets of Disruptions – One in Business and One in IT. Brown points out five alarming facts in his presentation:

  1. The return on assets (ROA) for U.S. firms has steadily fallen to almost one-quarter of 1965 levels.
  2. Similarly, the ROA performance gap between corporate winners and losers has increased over time, with the “winners” barely maintaining previous performance levels while the losers experience rapid performance deterioration.
  3. U.S. competitive intensity has more than doubled during that same time [i.e. the US has become twice as competitive – IG].
  4. Average Lifetime of S&P 500 companies [declined steadily over this period].
  5. However, in those same 40 years, labor productivity has doubled – largely due to advances in technology and business innovation.

Discussion of the full-fledged analysis that Brown derives based on these five facts is beyond the scope of this blog post [2]. However, one of the phenomena he highlights –  “The performance paradox: ROA has dropped in the face of increasing labor productivity” – is IMHO at the roots of the staggering IT debt we are staring at.

Put yourself in the shoes of your CFO or your CEO, weighing the five facts highlighted by Brown in the context of Highsmith’s technical debt curve. Unless you are one of the precious few winner companies, the only viable financial strategy you can follow is a margin strategy. You are very competitive (#3 above). You have already ridden the productivity curve (#5 above). However, growth is not demonstrable or not economically feasible given the investment it takes (#1 & #2 above). Needless to say, just thinking about being dropped out of the S&P 500 index sends cold sweat down your spine. The only way left to you to satisfy the quarterly expectations of Wall Street is to cut, cut and cut again anything that does not immediately contribute to your cashflow. You cut on-going refactoring of code even if your CTO and CIO have explained the technical debt curve to you in no uncertain terms. You are not happy to do so but you are willing to pay the price down the road. You are basically following a “survive to fight another day” strategy.

If you accept this explanation for the level of debt we are staring at, the core issue with respect to IT debt at the individual company level [3] is how “patient” (or “impatient”) investment capital is. Studies by Carlota Perez seem to indicate we are entering a phase of the techno-economic cycle in which investment capital will shift from financial speculation toward (the more “patient”) production capital. While this shift is starting to happens, you have the opportunity to apply “an ounce of prevention is worth a pound of cure” strategy with respect to the new code you will be developing.

My recommendation would be to combine technical debt measurements with software process change. The ability to measure technical debt through code analysis is a necessary but not sufficient condition for changing deep-rooted patterns. Once you institute a process policy like “stop the line whenever the level of technical debt rose,” you combine the “necessary” with the “sufficient” by tying the measurement to human behavior. A possible way to do so through a modified Agile/Scrum process is illustrated in Figure 2:

Figure 2: Process Control Model for Controlling Technical Debt

As you can see in Figure 2, you stop the line and convene an event-driven Agile meeting whenever the technical debt of a certain build exceeds that of the previous build. If ‘stopping the line’ with every such build is “too much of a good thing” for your environment, you can adopt statistical process control methods to gauge when the line should be stopped. (See Using 3σ  Control Limits in Software Engineering for a discussion of the settings appropriate for your environment.)

An absolutely critical question this analysis does not cover is “But how do we pay back our $1 trillion debt?!I will address this most important question in a forthcoming post which draws upon the threads of this post plus those in the preceding Part I.

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.

[2] See Hagel, Brown and Davison: The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion.

[3] As distinct from the core issue at the national level.

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.

The Supply Side of the Consumerization of Enterprise Software

with 10 comments

Source: http://www.flickr.com/photos/bertboerland/2944895894/

In my recent post about the consumerization of enterprise software I discussed two factors that are likely to accelerate the pace toward such consumerization:

  1. Any department/business unit that can get a service in entirety from an outside source is likely to do so without worrying about enterprise software and/or data center considerations. This is already happening in Marketing. As other functions start doing so, more and more links in the value chain of enterprise software will be “consumerized.” In other words, these services will be carried out without the involvement of the IT department.
  2. Once the switch-over costs from legacy code to state-of-the-art code are less than the steady state costs (to maintain and update legacy code), the “consumerization” of enterprise software is going to happen with ferocious urgency.

In this post I would like to add a third factor – the buying pattern. My contention is that the buying pattern for micro-apps will spread to enterprise application. Potential demand for buying in this way is huge. Supply for buying enterprise software as micros-apps is not quite there yet, but it would take only one smart vendor to start transforming the traditional pattern how enterprise software is chunked, offered and sold.

Think about your recent experience downloading an application to your smart mobile phone. You did not go through a six-month evaluation period; you did not do a comprehensive competitive analysis; you did not check how well the seller does customer support in Sumatra. You simply paid something like $7.99 and downloaded the application. You are more than happy if it fulfills your needs in a reasonable manner. If it does not, you simply buy another application with the functionality you desire. Maybe you are a little more cautious now and ask a friend or send an inquiry to your Twitter followers before you pick the new application. Whatever you might choose to do, the fundamental facts are: A) you can afford to lose $7.99; and, B) your time is more precious than the sunk cost of the application. You simply move on.

This buying pattern is not something that you are going to forget when you step into your office in the morning. It makes perfect sense to you and it would be good for your company. You would rather concentrate on your business than on the tricky language of clause number 734 in the contract that your department’s attorney prepared for licensing yet another piece of enterprise software.

The ‘$7.99 experience’ you and zillion other folks like you had over the past week or the past month makes enterprise software vendors extremely vulnerable. The “high-touch; high-margin; high-commitment” [1] business design is not sustainable once the purchase model changes.  The expensive machinery of professional services, system engineering and customer support is not affordable at the face of competition that constructs modular chunks of enterprise software and sells them at a price the customer can afford to write off (if they do not perform to satisfaction). Maybe the ceiling in the enterprise to ‘forget about this application and move on’ is no higher than $1,000 (instead of ‘no higher than $7.99’ for the private citizen), but a smart vendor can still make a lot of money on selling at one thousand dollars a pop to the enterprise.

The growing gap between “this lovely application on my iPhone” and the “headache of licensing traditional enterprise software” is an immense incentive for up-and-coming software vendors to use the ‘$7.99 experience’ as the heart of a new business design. This new business design can be simply summarized as “low-touch; low-margin; low commitment” [2]. And, yes, it is very disruptive to the incumbents…

My hunch is that the IT Service Management (ITSM) industry will be the first to crumble. The premise of “service delivery” sounds a little hollow in a cloud computing world characterized by “everything as a service” [3]. Would a buyer be really willing to pay for “service for the service” from a vendor who does not actually provide the underlying service?! It sounds like paying a Fidelity or a Vanguard investment manager to manage a portfolio of their own mutual funds for you…

All it takes for this shift to start – in ITSM or in another part of enterprise software –  is one successful vendor.

Footnotes:

[1] I am indebted to Annie Shum for this phrase.

[2] Ibid.

[3] I am indebted to Russ Daniels for this phrase.

Consumerization of Enterprise Software

with 7 comments

Source: http://www.flickr.com/photos/ross/3055802287/

Figure 1: Consumerization of IT

The devastation in traditional Publishing needs precious little mentioning. Just think about a brand like BusinessWeek selling for a meager cash offer in the $2 million to $5 million range, McGraw Hill getting into interactive text books through Inkling or Flipboard delivering “… your personalized social magazine” to your iPad. This devastation might not have gotten the attention that the plight of the ‘big three’ automobile manufacturers got, but in its own way it is as shocking as a visit to the abandoned properties in Detroit is.

As most of my clients do enterprise software, many of my discussions with them is about the consumerization of IT. From a day-to-day perspective this consumerization is primarily about six aspects:

  • Use of less expensive/consumer-focused components as infrastructure
  • ‘Pay as you go’ pricing (through Cloud pricing mechanisms/policies)
  • Use of web application interfaces to monitor IT infrastructure
  • Use of mobile and consumer based devices for accessing IT alerts and interfacing with systems
  • Use of the fast growing number of mobile applications to enhance productivity
  • Application of enterprise social networks and social software in the data center

From a strategic perspective, IT consumerization IMHO is all about the transformation toward “everything as a service” [1]. The virtuous cycle driven by Cloud, Mobile and Social manifests itself at three levels:

  • It obviously affects the IT folks with whom I discuss the subject. Immense changes are already taking place in many IT departments.
  • It affects their company. For example, the company might need to change the business design in order to optimize its supply chain.
  • It affects the clients of their company. Their definition of value changes these days faster than the time it takes the CIO I speak with to say “value.”

© Copyright 2010 Israel Gat

Figure 2: The Virtuous Cycle of Cloud, Mobile and Social

Sometimes I get a push-back from my clients on this topic. The push-back is usually rooted in the immense complexity (and fragility) of the enterprise software systems that had been built over the past ten, twenty or thirty years. The folks who push back on me point out that consumerization of IT will not scale big time until enterprise software gets “consumerized” or at least modernized.

I agree with this good counter-point but only up to a point. I believe two factors are likely to accelerate the pace toward “consumerization” of enterprise software:

  1. Any department/business unit that can get a service in entirety from an outside source is likely to do so without worrying about enterprise software and/or data center considerations. This is already happening in Marketing. As other functions start doing so, more and more links in the value chain of enterprise software will be “consumerized.” In other words, these services will be carried out without the involvement of the IT department.
  2. Once the switch-over costs from legacy code to state-of-the-art code are less than the steady state costs (to maintain and update legacy code), the “consumerization” of enterprise software is going to happen with ferocious urgency.

If you are in enterprise software you need to start modernizing your applications today. The reason is the imperative need to mitigate risk prior to reaching the end-point, almost irrespective of how far down the road the end-point might be.  See Llewellyn Falco‘s excellent video clip Rewriting Vs Refactoring for a crisp articulation of the risk involved in rewriting and why starting to refactor now is the best way to mitigate the risk.

Footnotes:

[1] The phrase “Everything as a Service” has been coined by Russ Daniels.