The price of SOA?

I just read a provocative blog on SOA which raises an interesting point. Articles on SOA tend to focus on the technical issues e.g. performance, standards etc. While I don’t agree with everything in the article, Robin Harris is correct in pointing out that how a new piece of infrastructure is perceived depends in part on the pricing mechanisms that end users see. Different IT departments charge in different ways. Some levy a “tax” on the business lines, perhaps based on a simply charge-back mechanism “retail is 20% of the business, so they pay 20% of the IT department’s costs”. Others charge out for services in a much more granular way e.g. a charge for each desktop, a charge for each GB of server storage, a charge for DBA services etc. The latter has the big advantage of being related to usage, meaning that heavy users of IT pay more, presumably in some relation to the costs that they cause the IT department to incur. The disadvantage is that the pricing can easily become over-complex, with user departments receiving vast itemised bills each month for storage, telecoms, data, networking, applications support etc in minute detail. This can cause some users to try and “game” the system by taking advantage of any flaws in the pricing model, which may make logical sense to the individual department but may actually cause the true costs to the enterprise to rise. For example if the IT department prices storage in bands then a department may resort to all kinds of tricks to avoid moving into the next pricing band, and yet the effort involved in fiddling around may exceed the true costs to the company of just buying some more storage.

At one time I worked in Esso UK, and a study was done of the pricing mechanism, which was of the complex/sophisticated type. The recommendation, from a bright young manager called Graham Nichols, was simply to scrap the charge-back systems altogether and just levy a simplistic charge by department. This actually saved three million pounds in costs, which is what it took for th charge-back systems to be administered. No doubt years later things have changed, but this was an example of how the internal systems added no value at all to the company, and by simplifying them could remove a layer of administration. The drawback to simplified systems like this is that there is no incentive for increased efficiency, since the departments know what they are going to get charged so perceive no extra cost in heavier usage of the systems. This may eventually cause heavier systems costs which will be charged back eventually to departments; it is a question of balancing the costs of the internal processes v the potential higher costs that may occur.

SOA is an example of core infrastructure which pricing mechanism have always struggled with i.e. how do you justify an investment in infrastructure which has no benefit at first, but will incrementally benefit future applications? However the investment in justified and charged back, a key point is that the investment should be justified, like any other. IT departments should view a new piece of infrastructure like other departments consider capital expenses e.g. a new fleet of trucks or a new factory. What is the payback compared to the investment? What is the IRR, NPV and time to break-even? I have not seen much if at all written about this aspect of SOA, and yet we all need to understand what productivity gains are actually going to occur before we head down this path. There may be significant productivity improvements, or none at all (indeed it could be worse than today) and yet commentators seem to take SOA as a given. If a whole industry moves in a certain direction then eventually this can be hard for end-user companies to avoid e.g. if you decided a decade or two ago that client/server was just an expensive way of distributing data from one safe, secure place (mainframe) to lots of unsafe and insecure places (PCs) then you could have tried to hang on to your mainframe, but eventually fewer and fewer applications would run on your old mainframe, and you would be obliged to switch whether you liked it or not. It is not yet clear that SOA has that kind of momentum. However I am sure that understanding its economic impact would be valuable for all sorts of reasons. I look forward to seeing someone addressing this issue seriously (I do not count breathless marketing material from vendors selling SOA services claiming 10:1 improvements in everything from productivity to quality, without any actual pesky real examples), but I am not holding my breath.

3 thoughts on “The price of SOA?”

  1. The first pedestrian will never pay for the full bridge. The lesson from this: investment for break through improvements (apart from the question wether of not SOA is break through) should be financed from a corporate budget and never from an individual project budget. Also investments in the companies “sewage systems” and should be financed from such a budget. Never ever put a surcharge to make up for the costs of teh IT dept. for on any purchase where IT has some kind of intermediate role (e.g. when hiring external staff do’nt charge the users or the projects with an amount per hour on top of the external tariff; this is the fastest way to have business users bypassing IT and start hiring their own extetnal contractors.)IS SOA breakthrough I don’t know. When i look to the problems companies has to get data from one internal silo to another I doubt that any user is interested in breaking up these silo’s into smaller pieces (he will suspect and I tend to believe he is right) that the data mess will only be worse. After all integration takes place on (master)data(definitions) and not on technology either EAI, ETL, Messaging or SOA or applications either SAP, Oracle or whatever acronym or vendor you can come up with.

  2. Indeed! I did an enterprise deal while at Shell with Business Objects. The way things worked, the cost of the deal was to be recovered from the Shell operating companies who wanted to buy licences. Just as in your case, of course, the marginal cost to Shell was zero. What happened? Business Objects distributors found that they suddenly were competing with an internal (Shell) competitor. They found that out internal price Shell centre were charging, and offered licenses to the operating companies at a dollar less than this. Now of course the Shell operating companies could now buy licences at one paper price from their parent company (no effective cost to Shell at all i.e. just a paper chase exercise) or pay real Shell money out to Business Objects distributors instead at one dollar less per license. Guess which they did in droves? I even had Shell guys calling me up asking me to match or beat the distributor price. A really great use of company time and money: let’s negotiate with our colleagues, and then give fresh money away that the company has already paid to buy software that we already own. An object lesson in large company realities.

  3. A former employer once sold a pile of licences to a major investment bank – buy 2, get 7 free was more or less the pitch. Hey, it was the last day of the quarter and we needed the money, dammit.

    The bank used the first licence on a project, and the second to build a ‘centre of competence’ which would be able to blaze a glorious trail for subsequent project teams to follow – and of course the CoC would charge them for the licences and their expertise.

    Sadly they tried to internally sell the licences at (price/9) – the average cost – rather than zero (the effective marginal cost). So over £1 million of fully paid for software sat on the shelf – other projects found it cheaper and easier to buy competitive products (with real money) than to hand over internal funny money.

    Show me an internal cross charge and I’ll show you its unintended side effects…

    Regards Nigel

Comments are closed.