Musing about making shared-service models work

For many years now, I’ve had the joy (?!?) of being involved in argument and debate about sharing in the enterprise. Sharing what? In the old days it used to be time on mainframes, as departments or even firms clubbed together to do things they couldn’t otherwise afford to do. Then it became space in data centres, as people figured out that having mainframes in office buildings wasn’t the brightest thing to do as office rents rose. By the time the PC came along and destroyed every vestige of “centralised control”, nobody was into sharing.

Every tinpot business unit became its own IT department, because it could. This disintermediation was a good thing, it stopped the tyrannical behaviour of the MIS guys, with their waterfall models and their GANTT charts and their PERT charts and their Thou-Shalt-Nots. Users could get their own staff to build things rather than wait for the bureaucratic processes of SSADM and PRINCE and whatever else their IT department was using. They could do what they liked. Heaven.

Or was it?

When they defenestrated the bathwater of 19th century project management, many of them threw the baby out the window as well. The baby of simple good practice, such as keeping notes of what you had and where you had it; what you had to worry about when you wanted to change things; how to upgrade; what to do when the sun stopped shining, or when you hit a problem.

Simple disciplines. Simple things to do that kept problems at bay. But it was too late, baby went with bathwater.

And there were consequences. Consequences such as the Year 2000 panic. My personal estimate is that less than 10% of the expense associated with Y2K had anything to do with code. It was all about replacing the disciplines and controls that used to be there. Strange things happen when you mix panic with consultants.
But that was a long time ago. Since then, terms like consolidation and virtualisation and service orientation and utility computing and grid computing and a bunch of other things have come out and bred like rabbits, rabbits whose sole aim was to prove Fibonacci wrong.

And in between, we’ve learnt a little bit about component architectures and re-use. And every time we do this, we land up with the same objectors, the same objections. You see them everywhere:

The Reuseniks: These are reuse refuseniks, conscientious objectors to code-sharing. Habitual wheel-reinventors. Sometimes seen brandishing terms like privacy and confidentiality and competitive edge, even within organisations. Scary. Be afraid. Be very afraid.

Freasy Riders: These guys will do anything, provided they don’t have to pay. Close relatives of the Credit Grabbers, they jump on sharing bandwagons only after all the hard work’s been done and the entry costs have come down. They then employ an army of checkers to nickel-and-dime their shared-service bills. Woeful.

Cyclopaths: These guys get on the shared-service bandwagon without any ado, and then get stuck on it. They are fundamentally unable to cooperate with the rest of the platform users, objecting to every plan to change the status quo, using specious operational risk or even ROI arguments. They act as drag factors on the rest of the shared-service population, and often create an environment where, one by one, the others just leave. Which creates its own problems, as the shared-service bills get doled out over a smaller population.

Of the three, the cyclopaths are the most dangerous, because they seem to believe, because they seem to cooperate. Insidious.
How do we deal with them? In the end, I think it comes down to economics. Not accounting, economics.

As things commoditise, the ability to consolidate increases; there is an implied pace of standardisation, and over time there’s an incredible scaling effect. A tipping point is reached, and the shared-service models get traction.

All this is easy to say, but we’re some way from that destination. We may be on the last lap, but we’re not there yet.

Which is why we need to spend time thinking about the economics of shared-service models. How to price the utility. How to prevent first-mover disadvantage. How to dissuade freeriders. How to get leavers to pay their fair share.

A number of you must have done research on all this already. Why not share it with the rest of us? Comments welcome.

In the meantime, I shall busy myself with reading more about game theory and Talmudic wisdom and prisoner’s dilemmas. And dip every now and then into The Numbers Guy, Carl Bialik. [If you haven’t discovered Carl, I strongly recommend you do, he’s a fun read. Sort of Asimov-and-Gamow-meet-John-Allen-Paulos].

Like this:

Related

3 thoughts on “Musing about making shared-service models work”

I do wonder about how well classic economics applies to digital resources, Clay Shirky expounded on this explaining how “The Tragerdy of the Commons” doesn’t apply to Napster (heh, Y2K) “In Praise of Freeloading”: http://www.openp2p.com/lpt/a/485

Possibly one of the reasons why Cyclopaths behave as they do is due to the difficulties in enhancing and extending existing services without breaking existing interactions – one of my goals in participating at the W3C is to break away from the copy and corrupt another stovepipe model for services – after all HTML and HTTP’s extensibility is why we have a Web. Getting agreements from the commons to change is very difficult, that’s why even in Open Source, a single entity such as Apache having ownership of a resource can make changes a project where each contributer maintains individual ownership rarely can.

I have worked for a number of global enterprises that have had ambitions to realise the Nirvana of Shared IT Services. Some of these Enterprises have been highly successful, and some less so. Looking back it is interesting to note that in each case where the Enterprise was successful there were a number of common features;

* The Enterprise changed the way IT projects were funded;
* The Enterprise focussed on Infrastructure first; Processes second and Applications last;
* The Enterprise adopted a Product approach to IT;
* The Enterprise recognised the need to change the way they did business, not just IT;

The biggest barriers that all of these Enterprises encountered in realising Shared Services were; finding a way of funding the initial Infrastructure and Application Migration costs; and addressing the disconnect between the IT organisation and the Business.

In cases where Enterprises realised greatest success, there was strong support for the inititives at board level, the business was transformed in-line with the IT transformation, and very strict funding controls were put in place, to prevent the delivery of competing solutions and non-compliant projects across the Enterprise.

Where Enterprises were not able to exercise such tight funding controls, Shared Services were only ever realised at the Infrastructure level, where commoditisation is relatively simple and painless to acheive.