« Pointing The First Finger, Having the Last Word | Main | Linking Economy to Profitability »

February 10, 2006

What's So Hard About Software?

"I know that half of my marketing budget is a total waste. I just don't know which half!" That little twist on some wisdom attributed to retailer John Wanamaker pretty well sums up what most organizations know about their software assets. They just don't have the kind of information they can rely on to get past that point.

To the very same point, readers of InfoWorld in February got cover-story confirmation of what they probably knew all along -- the madness in their enterprise data is methodical, and it's time to see the shrink.

The key points of the diagnosis are especially familiar to organizations struggling with managing IT assets. Gartner maintains that on the maturity ladder of asset management, level three (of five) is where most organizations need to be, but most organizations get stuck on level two. Now, it's fair to say that most managers, checking themselves out, consider themselves to be effective if the future provoked by their decisions is simply better than the past they decided to change. But what appears to happen too often in asset management is that things get different allright... just not better.

The issue is not the confidence to make decisions; they do get made all the time. But because management is so reliant on measurement, and measurement is reliant on description, the quality of identifying data is where most of the management effectiveness is made or broken. Without decent data, the decisions aren't worth very much.

In capturing data about IT assets, perhaps little else is as difficult as tracking software. Not only is software made, bought, borrowed, stolen, found and inherited, but it hides and changes, too. Even if we include only the occasions where any of that was really intentional, the results offer a dazzling array of subjects to track and difficulties in doing it. The final irony is that as software moves from its origins to its destination, it legitimately gets tracked in different ways for different reasons by different parties. (Who knows the real identity of the man with a thousand faces?)

As we hear pretty regularly now, the definition of "crazy" is doing the same thing over and over and expecting a different result. Since frustration with information about software assets is often really high for everyone in the chain of supply and demand, it's evident that the things we've done about it before, and keep doing, aren't working. So are we crazy, or is it just that we don't have any alternatives?

I.

Descriptions of software assets vary because of the diverse reasons for handling the software. Each party responsible for the handling naturally tries to optimize their description of the software for the particular purpose behind their own responsibility. In essence, the descriptive difference that they cultivate is part of their effort to raise their performance.

The irony is that, in an important way, this "performance" increase turns out not to be effective. Yet the practice of describing an asset in multiple ways does not often change.

To back up that claim, how do we define effectiveness? The two biggest impacts that software has on the company are on expense (operating costs) and productivity. In the organization's locations or processes, there are thousands of points at which expense or productivity can be affected. Factoring in that diversity, software decisions must improve both expenses and productivity to be called effective. But the tendency is to think in terms of each separate decision having a tolerable effect. This often goes mostly into stressing features and lowering the price. But in the mid-to-long term, if production generates excessive risks, then the cost of handling risks negates the savings of lower expense; and if cost-reduction generates excessive restrictions on acquisition, then the inadequacy of the acquired software undermines the potential level of productivity. So instead of a double-win situation we get a double-loss, and a vicious cycle to boot.

This points out that many decisions about software are made with good intentions but simply (and profoundly) are made out of context.

II.

Software management, as opposed to software tracking, tries to determine what patterns of software demand and usage correspond most closely with actual improvement or deterioration of sustainable expense and productivity. To find those patterns, management must do an analysis of what is there. To do the analysis, the identification of what is there must be valid. Unfortunately, the evidence of what is there is often highly unreliable -- unpredictably incomplete, misleading, or competing -- until it has been vetted, cleaned, tested and certified.

If those last few words ring a bell, it's probably because they are so recognizable as the same procedure used to transform most raw material input into a resource. It unglamorously (but crucially!) steps us down from "information management" to "data processing", where we can get enough traction to know that from then on we'll actually go where we steer.

The key barriers to effective processing of asset data stretch across the usual three dimensions of people, process and technology. Luckily, people are becoming less of a problem as the need to put skilled analysts on the problem of integrating disparate data becomes increasingly well understood and supported as a role and as a job. Meanwhile, technology continuously improves in its ability to automatically detect and announce when something has been added, moved, changed or deleted -- and to accept and understand external rules for doing so. That means different systems can better communicate with each other and/or with a neutral third system.

So, people are getting better at revealing the scope and depth of the problem, and tools are getting better at manipulating elements of its solution. But the remaining frontier is process, through which activity becomes achievement.

The key to the successful processing of disparate asset data is to understand how it became disparate in the first place. This understanding is represented by a model of the software asset lifecycle. As software goes through different phases from creation to distribution, use and disposal, each phase cultivates and records certain kinds of descriptions by efforts of parties responsible for the software at that phase. Since a given phase may also feature multiple parties with differing responsibilities and stakes, each party may have its own way of referring to the software at each phase. To process the data adequately enough for delivering a highly confident inventory, the process must know how to hit the various parties at all the various phases.

Aside from the challenge of bringing such comprehensive knowledge to the task, the big barriers to getting the job done are its cost payback and performance urgency. One way for organizations to address these barriers is to consider the task itself as an investment. If the cost of the task can permanently improve the cost of software ownership, and if the increase in information reliability immediately minimizes or eliminates management mistakes across the asset lifecycle, then the return on investing in the task is definitely positive and likely pretty high.

What are the pains from management mistakes that exemplify the urgency?

Try corporate fines for software license violations; failed systems rollouts due to software incompatibilities; and the combined bills for unnecessary redundant purchases and overly complicated technical support.

Then add on top of that the big issues that provoke them -- such as SarbOx compliance, which is mandatory regardless of the underlying expense it will exacerbate in process redevelopment, project management and purchases of "up-to-snuff" functionality. If it's not SarbOx then maybe it's a departmental consolidation, a new market-segment launch, or retirement of legacy systems.

Whatever: urgency is probably not missing. But practical opportunity to respond is the point of contention.

To define the opportunity, it helps to pick a target and a scope of impact, and then plan an attack.

One somewhat obvious approach is to begin sorting out the purchasing data (where acquisition cost practices can definitely be analyzed) and the inventory data (where distribution practices can be analyzed) -- and reconciling them with each other. The question of whether you actually have what you're supposed to have is the signature focus of this approach. But the answer first obtainable may or may not be reliable. The real point is to discover whether there is any control of the asset's lifecycle, and to begin instituting enough control so that the company henceforth can determine whether its production will predictably leverage the purchase value of the software. This discovery will indicate points of operation that are potential points of failure underlying the demand from business units, regulations, and funding caps. Eliminating these points of failure lays the groundwork for true and positive ROI from the software.

Posted by Malcolm Ryder at February 10, 2006 11:07 AM

Comments

Post a comment