The packages - customisation MQ

I got Rt'ed today on the #ITF11 hashtag:

RT @MartijnLinssen: @johnrrymer @TomGrantForr There is no one-size-fits-all. Pure packages is wrong, as is pure customisation #ITF11 >YES

and that's basically all I have to say about it - not

There is a human tendency to do either-or. Black or white, good or bad, pretty or ugly - well you finish that seemingless list yourself if you want.
Stephen Wolinsky describes that in his theory of False Core-False Self. Nothing to do with IT, but it perfectly describes how we humans operate - choosing my words very carefully here

Yin and yang describe the world as it is: a bit of this, and a bit of that, keeping each other in balance. Well, that's exactly as it should be in IT. But how is it, in IT?

In the beginning there was a void - so everything had to be built from scratch. At some point, there were ready-made building blocks, useful in one situation and perhaps re-usable in another situation. Yet, at that point, standardisation had introduced itself and programmers found themselves rebuilding their re-usable building blocks to adhere to programming standards in place at projects and customers - that form of standardisation was at a nitty-gritty level

Then, Component Based Development saw the light (I'm noticing the wiki getting hijacked here, so please ignore the rest). CBD failed because it was an IT party and the semantics were fully ignored - apart from the fact that the needed standardisation on the lower infrastructure level wasn't nearly as much in place as it is now

Object Oriented Programming followed up and almost immediately died on the spot (I just love to state that). Check out the link and you'll pity the wiki administrators

So, it was decided: customisation was dead, building-block stuff was doomed to fail, and we swung to the outer end of the scale: no customisation at all

Siebel, SAP, and a truckload of other packages saw the light. They even differentiated in verticals: parts of their package to buy and implement, aimed at separate industries.
Bliss? Of course not. These packages still had to be implemented in the existing IT-landscape, having to integrate with their brothers and sisters already there. And by default, packages are, and always will be, very bad at integration - unless they take my advice

So then, companies swung even beyond the outer end of the scale:  they implemented packages enterprise-wide. Coloured the entire enterprise IT purple, or blue, or green. costing tens and hundreds of millions of dollars in implementation and consultancy - yes, consultancy- not to mention the support costs at 15% to 20% a year

That way, an average e.g. SAP project implied a 5-year or even 10-year contract, pushing the point-of-no-return further and further back to the past every day. The still needed customisation, combined with the naturally lagging package modules, made this a costly and sometimes crippling exercise - many of these mammoth exercises have failed

Why? Simple

The business always leads, you can't code up front for a business opportunity or market that's not there yet, so these packages usually lagged a few years. Tied in the straight-jacket of an enterprise-wide package implementation, companies either started to customise it to death, or find it nearly impossible to integrate their specials with it

The answer? The packages - customisation MQ

It's all about standardisation and dynamics, infrastructure versus business, plumbing versus the devices you use on top of that same plumbing. Electricity, gas and water are so highly standardised that you can put all kinds of new sexy and shiny appliances on top of them - the same goes for IT

What is static in your business? The secondary processes - HR, payroll, billing, invoicing, leasing, etc. If you want to diversify on those, you're either an idiot or in the wrong core business. Buy a package for those, please do, don't customise a thing and leave it at that

Want to diversify on your secondary processes? Careful now - why on earth? Maybe you want to show some flexibility to your vendors, suppliers, customers, oh wait - maybe even your employees. Well, there's a trade-off here, as usual: how badly do you want to do those pleasures? And to what extent will these pleasures for others still be pleasures for you? Because you can be just in the ball park here, or out of it - and that will make for a huge price difference

What is dynamic in your business? Your primary processes, the ones you want live and die for - whatever the hell they are. You do business in a certain area, with certain customers, and of course you just manage to do those slightly different than your competition, or else you'd be just another boring number. Package that? Not to the fullest, that is impossible, but maybe you can take some advantage of basic business here that you do share with your dearly beloved competitors, market and package-selling vendors

Want to diversify on your primary processes? Now that *is* a dumb question isn't it?
You're eager, you're lean, you're mean, maybe even all of that together, you're a true business innovator having a laugh at all your competitors because you always sniff a business opportunity way before most others get a hunch. Packages for that? To you they'll be like laggards, it will take months but usually years before they mange to develop what you're up to - if they even can

Oh and don't forget - in every business you'll have to integrate your specials into the package, or vice versa. The need for customisation only dies if your USP's do