An interesting piece from Monday’s Financial Times - Study urges IT valuation rethink. What this study says is: IT is an asset, therefore companies should value the asset show it as an asset on the books. This isn’t such a new idea, some people have been arguing this for a while but INSEAD and Micro Focus have written a report and got some publicity for the idea. (See also the Micro Focus press release.)
I have to say I agree with the central argument being made here. IT systems are an asset to a business, they allow the business to operate, they cost money to develop and without them there would be a big hole in the organization. Companies count machines, buildings and even brands as assets but not IT systems. In most companies if the IT system disappeared tomorrow it would need to be replaced and that would cost money.
Actually companies do carry some IT elements as assets - hardware. Mainframes, PCs, printers etc. are bought, counted as assets and devalued over time. So actually, when we talk about putting IT on the balance sheet we are really talking about the software.
Now this has some interesting consequences - not all of which my younger self would be happy to hear. Suppose for the moment software is considered an asset, what happens?
Well firstly you get an increase in your balance sheet. This is good, it shows the company is worth more. It also means that software can be depreciated over time, as with hardware, we can aim to write it off over time. This might make it easier to end of life a system after a period of time. Given that software deteriorates over time this could be a good thing.
However, this also means you can’t dispose of it overnight. How many developers faced with a poor system cry: “We can’t maintain it! We need to re-write it” ? How many managers accept this argument. If software is an asset this decision is changed significantly.
Neither could you throw away failed projects so easily. Many companies bury failed projects. Rather than admit to an embarrassing failure they simply don’t and loose the costs in expenditure. However if you are building an asset and suddenly it disappears then you will have some explaining to do.
For both these reasons (and others) putting software on the balance sheet will make it more difficult to get rid of existing systems. This is the bit my younger self would hate.
When I was still programming I saw lots of really bad software. I always wanted to re-write it and sometimes I did. However rewriting is no panacea. It is often (usually) better for the business to continue with the old system. But in doing so you have to improve it. You have to move it in the right direction or else it will become impossible to work with.
This is what interests me now: how can a business maintain legacy systems? This is the challenge I now embrace as a manager.
Now, if we start counting software as an asset there will be more incentive to maintain the software and keep it alive for longer. This means we will invest in the software to keep the asset. Of course we’re going to need tools to value the software - INSEAD suggest one tool and my guess is Micro Focus can sell you a product to do so.
So what is the net effect?
Well I think this approach would allow better reasoning about the software life-cycle. If a piece of software is only going to be used once then it isn’t going to be an asset and we treat it as such. However if we are going to count it as an asset we can decide whether we are going to devalue it over time, and plan in advance for retirement or replacement. Or if we are going to maintain it and keep (or increase) the value on the books then we need to invest in it. Either way we get to reason about the future of the software more logically.
Now imagine we had a tool that assess software value. Point it at the source code control system, put in some economic numbers and bingo! Your software is worth $10,000,000. Next year, with inflation and depreciation the software may only be worth $9,000,000. So there is an incentive to invest up to $1,000,000 in improving the software, increasing functionality, or code quality, or making it easier to use. That changes the game.
(I’m sure Micro Focus, who specialise in tools for legacy (and particularly COBOL) systems are well aware of this. I for one hope we hear more about this idea.)
We tend to think our software will have a short life. But we already know that some software systems are 20, 30 or 40 years old. (Remember the millennium bug?) These are major engineering achievements.
We take it for granted than major engineering achievements are still there. The Forth Rail bridge was opened in 1890. Nearly 120 years later it still works, it is an asset to the nation. St Pancras station in London was reopened yesterday after refurbishment, originally opened in 1877 it is still an active part of the economy 130 years later and it is an asset to National Rail.
On this basis there is every reason to believe that software being written today will be in in use in 2127. Isn’t it about time we started treating it as such?
I have to say I agree with the central argument being made here. IT systems are an asset to a business, they allow the business to operate, they cost money to develop and without them there would be a big hole in the organization. Companies count machines, buildings and even brands as assets but not IT systems. In most companies if the IT system disappeared tomorrow it would need to be replaced and that would cost money.
Actually companies do carry some IT elements as assets - hardware. Mainframes, PCs, printers etc. are bought, counted as assets and devalued over time. So actually, when we talk about putting IT on the balance sheet we are really talking about the software.
Now this has some interesting consequences - not all of which my younger self would be happy to hear. Suppose for the moment software is considered an asset, what happens?
Well firstly you get an increase in your balance sheet. This is good, it shows the company is worth more. It also means that software can be depreciated over time, as with hardware, we can aim to write it off over time. This might make it easier to end of life a system after a period of time. Given that software deteriorates over time this could be a good thing.
However, this also means you can’t dispose of it overnight. How many developers faced with a poor system cry: “We can’t maintain it! We need to re-write it” ? How many managers accept this argument. If software is an asset this decision is changed significantly.
Neither could you throw away failed projects so easily. Many companies bury failed projects. Rather than admit to an embarrassing failure they simply don’t and loose the costs in expenditure. However if you are building an asset and suddenly it disappears then you will have some explaining to do.
For both these reasons (and others) putting software on the balance sheet will make it more difficult to get rid of existing systems. This is the bit my younger self would hate.
When I was still programming I saw lots of really bad software. I always wanted to re-write it and sometimes I did. However rewriting is no panacea. It is often (usually) better for the business to continue with the old system. But in doing so you have to improve it. You have to move it in the right direction or else it will become impossible to work with.
This is what interests me now: how can a business maintain legacy systems? This is the challenge I now embrace as a manager.
Now, if we start counting software as an asset there will be more incentive to maintain the software and keep it alive for longer. This means we will invest in the software to keep the asset. Of course we’re going to need tools to value the software - INSEAD suggest one tool and my guess is Micro Focus can sell you a product to do so.
So what is the net effect?
Well I think this approach would allow better reasoning about the software life-cycle. If a piece of software is only going to be used once then it isn’t going to be an asset and we treat it as such. However if we are going to count it as an asset we can decide whether we are going to devalue it over time, and plan in advance for retirement or replacement. Or if we are going to maintain it and keep (or increase) the value on the books then we need to invest in it. Either way we get to reason about the future of the software more logically.
Now imagine we had a tool that assess software value. Point it at the source code control system, put in some economic numbers and bingo! Your software is worth $10,000,000. Next year, with inflation and depreciation the software may only be worth $9,000,000. So there is an incentive to invest up to $1,000,000 in improving the software, increasing functionality, or code quality, or making it easier to use. That changes the game.
(I’m sure Micro Focus, who specialise in tools for legacy (and particularly COBOL) systems are well aware of this. I for one hope we hear more about this idea.)
We tend to think our software will have a short life. But we already know that some software systems are 20, 30 or 40 years old. (Remember the millennium bug?) These are major engineering achievements.
We take it for granted than major engineering achievements are still there. The Forth Rail bridge was opened in 1890. Nearly 120 years later it still works, it is an asset to the nation. St Pancras station in London was reopened yesterday after refurbishment, originally opened in 1877 it is still an active part of the economy 130 years later and it is an asset to National Rail.
On this basis there is every reason to believe that software being written today will be in in use in 2127. Isn’t it about time we started treating it as such?
No comments:
Post a Comment
Note: only a member of this blog may post a comment.