Skip to Content

Cost of Standardization

Standardization is not for free – I do not think that anyone is arguing in that direction, therefore I personally consider a cost based view on standardization as very essential.

Costs are driven by factors like the effort needed to standardize, which could be a bigger environment or the delayed time to market. Of course standardization also provides huge saving potentials for integration costs.

Looking back to history of standardization I see two things a) the degree of standardization is increasing and b) there is some ‘natural’ trend or tendency that standardization projects and enterprises appear. Here I completely agree with a comment on my last blog – there is some kind of evolution theory that one can apply to the idea of standards.
And one selection criteria of the standards evolution is cost – ‘standards’ grow partially widely but mainly the ones that have a positive business case are surviving. On the other hand the environment might inhibit some developments e.g. when there is one hurdle that is hard to take. In the case of standardization in banking this is in my opinion the proprietary legacy world of banking IT. The evolution did not force banking IT drastically enough to develop the necessary ‘agility-genes’ – one could survive long enough without them in many areas.
In specific situations this has of course happened, we know the examples inter bank payments, security orders and some other domains. Once I heard the sentence that the low hanging fruits are already picked the other might not be worth the investment.

This is the core issue I see for standardization in banking – especially if we think about Outsourcing and Insourcing of core processes or it related entities of a bank. Not having standardized the complex internal banking landscapes slows down the change of the value chain rather heavily. The integration cost of big outsourcing project ruin regularly the business case of the outsourcing project – to be precise I do not talk about outsourcing the complete IT but only parts of it.

You see I do not argue any more for any of the two extremes – not standardization versus complete standardization – but I have arrived at a major question: What should be standardized? Business Process, the Banking IT landscape or Banking IT services? And how detailed and precise should such a standard be? Should we try to identify hotspots and define these high priority topics down to a level of MDA – a platform specific model that can be used to generate IT-artefacts? Or can we start with a high level picture and e.g. define a common IT component landscape (the ‘boxes’ and some consensus on what they contain)?

I think we have to do both – evolution has to happen from many directions. We need standards that are implemented to proof their value (justify the business case) and we need an evolution to a common understanding of the big picture.

And the good thing about evolution is that you do not need to define the target from the beginning. We can start on the big picture and with the details in parallel – an iterative approach to use a term that fits more to modern IT talks.
We neither solve the problem from one direction only that is clear for me. The path we follow with this iterative approach is however stony regarding the consistency of the results. We pay our due in a tricky and maybe expensive governance process. Which is a good closing remark – because it fits to the topic of today….

Be the first to leave a comment
You must be Logged on to comment or reply to a post.