Cutting the Cost of Change over Just Cutting Cost

Many businesses talk about cutting cost, especially at the moment, and IT is often an easy target. The problem with focusing on just cutting cost is that you can increase your future cost of change.

The most obvious example is when you let people go who are experts in your legacy systems, you certainly cut cost as you are not paying their salary any longer - but at the same time you've just constrained your ability to deliver changes to those legacy systems.

Now if a business has been focused on cutting cost for a while chances are that any initiatives to pull functionality out of a legacy systems (where change might be costly) into newer systems (where, hopefully, changes are cheaper) will not have happened.

So you've been cutting opex, which funds the ability to change existing systems, and often also cutting capex which funds the creation of new systems or the movement of existing functionality into systems that require less opex.

So the end result of cost cutting is that the cost of change will increase over time, you are removing capability to change systems while at the same time restricting the ability to replace those systems. Eventually you reach a point where cost of change is high enough to mean you can't make the business case for even small changes. At that point you might decide to invest in replacing the legacy systems that have become so expensive to change - but chances are that you no longer understand what those systems do and that it's beyond the capacity of the business to fund replacing them. Even if you can afford to replace them what do you do in the mean time, it might takes months or years to build the replacement.

So what is the alternative? One might be to focus on cutting the cost of change as opposed to just cutting cost. So incrementally invest to move functionality off legacy systems into new systems or to keep software in a reasonable shape in the first place. Consider viewing systems as things that constantly evolve as opposed to things you grow to a certain point and then throw over the fence into support. Think about architectural approaches that reduce coupling and dependencies between systems. These are just suggestions and there are a lot of other things you could do, chances are the people on the ground will have some good idea of where to start.

If you can cut the cost of change that means you can get more done for less money, which is cutting your cost. Focus on the cost of change may well be the thing to measure and to drive down over time, as opposed to just cost per se.

Great post on "Bad Behaviour" in projects

These all ring very true.

Will cost per transaction kill your business?

Imagine a business, Major Widgets Plc, that makes money by selling things in bulk, they sell a batch of 20,000 widgets on to a high street retailer who then sells the individual units. Each time Major Widgets sells a batch it costs them $1.5 to process that sale, as the overall cost of a batch is $20,000 that is less than 1 tenth of a percent cost overhead, pretty good. As they only sell 1000 batches per month they also process all the orders at the end of month in a legacy batch processing system. They are feeling pretty pleased with themselves.

Now imagine a new business, Overlooked Upstart Inc., who also sell widgets. They do something rather different though, they sell widgets directly to the consumer as individual units. They currently sell only around 10% of the total number of widgets per month of Major Widgets, so instead of 1000 transactions per month this means they have to do 2 million. It actually costs them $0.001 to process each transaction and as they charge only $1 per widget that is actually more cost overhead in percentage terms than Major Widgets. Overlooked Upstart also process each transaction as and when it happens; as their business is spread reasonably over the month that is about 66000 per day or around 47 per minute. They run this system on a couple of commodity blade servers and know they can scale up to a few hundred orders per minute without too much cost. They too are feeling pretty pleased with themselves because.....

...in this hypothetical universe it turns out consumers really like the convenience of buying widgets online directly without the high street retailer taking a cut. Major Widgets sees a downturn, the retailers only want 15,000 widgets per month, this is a problem and if it continues they'll be in serious trouble in a few years time.

So Major Widgets decides to launch online sales themselves and set the goal of having 10% of total widget sales online. The first challenge is that all the orders are currently keyed in by hand at the rate of about 30 per day, there is no electronic way to capture the orders at the required rate of 66000 a day without hiring a few new people(!). The second challenge is that the legacy billing system can only run on the last Monday of the month within a 4 hour time window - which comes out at around 140 transactions per second (around 130 per second faster than their current system can do). The harsh truth is that they cannot currently compete selling individual widgets due to their high cost per transaction and aged infrastructure.

Ok, not the end of the world, they just need to spend money on a few new systems. But it turns out it's not that simple, they'd been seeing IT as a inconvenient cost for some time and over the past few years have been cutting both operational and capital spending as well outsourcing the support as part of a multiyear contract. To make things worse all the people who knew how all the systems were tied together have left, the person who wrote the cobol transaction processing system retired and all the web developers have been poached by some company called Overlooked Upstart Inc.

Major Widgets come to realize that they are best off being taken over by someone who has infrastructure with low cost per transaction and high scalability........

Of course this is a simplified made up example and I'm lucky enough to work with clients who see IT as an integral part of what they do, they are well aware of their legacy systems and what online offerings can require in terms of scaling and cost.

However I am still amazed to hear of some companies who talk as if the internet is going to go away and that IT is just a cost to be controlled. What are they going to do when someone new moves into their market? This isn't really a new phenomena either, market de-regulation in equity trading led to a massive up turn in volumes that put some small brokerages out of business. I'm sure there are other examples as well.

The Amazon.com Technology Platform: Building Blocks for Innovation

Werner Vogels at InfoQ, well worth watching if you've not seen this presentation before.

Nice write up on technical debt

Via Dan Creswell and well worth reading: Technical Debt

Getting Growl notifications on your Squeezebox display

Just treated myself to a new gadget, a Squeezebox and I thought how nice it would be to have the display show Growl notifications. It turned out to be very easy, growl just uses css and html to control the notifications and the slimserver lets me hit a url to display text on the Squeezebox's display.

So I created myself a custom notification plugin following the instructions on the growl site and added the following to the template.html inside of the body.

<iframe src="http://localhost:9000/status.txt?p0=display&p1=%title%&p2=%text%&p3=20" height="0" width="0" frameborder="0" scrolling="no"/>

And it just worked, I also get notifications from digiguide running on my windows box as I send them to my Mac mini using ruby-growl.

Going to oopsla this year

Looks like I will be attending oopsla this year in Montreal, excited to be going to the conference and looking forwards to visiting Canada for the first time.

Drop me a note if you are going along!