Copyright © 2009 Corvus International Inc. All Rights Reserved
If we managed finances in
the way we manage software. . .
...somebody would go to prison.
Phillip G. Armour
Communications of the ACM - 3d hard copy, 2005
Sarbanes-Oxley Act of 2002
TITLE III Section 302 (partial synopsis)
“(4) The signing officers (A) are responsible for establishing
and maintaining internal (financial) controls (B) have designed
such internal controls to ensure that material information
relating to the issuer… is made known (C) have evaluated the
effectiveness of the internal controls… (D) have presented
their conclusions about the effectiveness of the internal controls"
The Sarbanes Oxley Act of 2002 (SOX) explicitly refers to the validity and accuracy of the financial reporting of publicly quoted companies. But the act is so vaguely worded that it could be construed (and could be enforced) to apply to many other aspects of running a business. Specifically, it could conceivably be applied to software projects.
Software is an asset too, but what's it worth?
Software projects cost money, and we assume that we get some valuable return for our investment in them. But we have some trouble figuring out what these are. As the CIO of a large government agency remarked to me: "There are two things we don't have a good handle on: what our systems cost, and what they are worth..."
Many companies have a poor track record of recording the total costs of their projects and few, if any, explicitly determine their worth. Part of the fiduciary responsibilities of executives under SOX is to (a) ensure that the investments of the company are sound and (b) that they have caused to have built and maintain systems that inform them of the cost and value of these investments. If a company was buying bonds, it would ensure it had followed certain procedures: checking the bond rating, determining the level of bond insurance, calculating the yield, etc. If a company was investing in equipment, it would perform a cost-benefit analysis and track to that analysis; as the equipment ages, the company would track and account for the depreciating value of the equipment according to a well-defined schedule.
It is a sobering thought that there is no way to do this for software projects and the systems they produce. We have few systems for consistently predicting and monitoring the cost of projects and no mechanisms for valuing and depreciating the same. In fact the software assets don't even appear on the company balance sheet (!)
Companies have a better idea what the value of their paper clips are than their software systems. Given that we are now in "knowledge economy" era where the primary asset is knowledge, we build and store this asset in the software medium, and we don't know how to account this is a terrible indictment of the software industry.
We simply would not let this happen for any other asset.