Skip to Content

This headline seems to have some truth in it, let me take a look at that a bit closer.

If everybody offers the same – let’s say, the same services – and that is what standardization is all about – there seems almost no possibility to make your own points. That sounds logical and is partially true for sure.

Looking at this question I see two major dimensions, the question “what is standardized” and the second one “how deeply or detailed are things standardized”. If the answer is “everything to 100%” then we safely can make the headline our only and single true statement. But this is very likely not happening and by the way nor desired nor needed.


But then the question is: What will and should be standardized?

Diving into that question leads a bit away from the unique selling proposition for a moment. So let us pause the first question and look into the dimensions of standardization. I am leaving out everything below the content or application layer, assuming that proper layering with respect to infrastructure provides the freedom to do so and that these rather technical layers have their own challenges – which I will not discuss here.


Let me call the layer in scope the ‘semantic layer’. I see business applications or business components, object and data models, service definitions (one part of it), processes and the like as first class citizens in that layer.

These elements, view points or dimensions of standardization are not independent from each other – as examples show: A full blown service definition requires an understanding about the business semantic, which can be e.g. expressed in an object- or data model. Another example is the usage and need of business objects and services in an orchestration or choreography that typically constitutes business processes.

Let me turn the question back to its origination about standardization and let me do two “what ifs” from specific – of course vastly simplified – view points:


Scenario a) – I am a major consumer of services:

As a consumer of services I am the owner of my own processes and do not need to take care for ‘any’ alignment with a provider on process level. I consume services, which are of course well documented and thus I know the outcome of a service call, and compose them into new applications.

I do not care, if a service call is a single task or action (e.g. a change on a database table) or a trigger to start a complex process of its own –  that is one idea of service orientation. Thus I am fine if the services are standardized – best for me if I can switch providers on the fly. Nice examples are e.g. mash ups.


Scenario b) – I am thinking about a new B2B-collaboration

Let us assume that this collaboration requires more than a single service call but a more complex interaction. Often multiple messages have to be exchanged in a well defined scenario or process. To be able to do coordinate this message exchange in a live scenario nearly all details have to be specified, the messages and date elements, the process steps and their sequence, the appropriate exception handling and the like.


This to simple scenarios already show, that the overall use case is determinedly influencing what we need to standardized.


Additionally both scenarios show, that the degree of standardization is not immediately predetermined upfront.

Especially in scenario ‘b’ the question is interesting, one could think about a mandatory core standard that can be enhanced by additional elements. The enhancement would give room for bringing in a unique proposition but of course would require additional effort for an actual implementation.

In scenario ‘a’ one can easily use a classical mapping approach in the composition, thus there is no need for a perfect match upfront.

This leads for me to a very interesting question, where is the optimum of standardization generically or even in specific cases and can we calculate that from a business perspective?

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Vijay Vijayasankar
    I show and breed dogs in competitions, and one thing we try to sustain in our breed is what is called “type”. Type distinguishes one breed from another, even if there are a lot of similarities on first sight. Each breed evolved for a purpose and we like to keep it that way so that folks have a larger pool to select their companions from. Without spending attention on type, we will end up with a “generic yellow dog” and that is what all good breeders try to avoid.
    Your blog reminded me of this principle.

    I think only a small subset of services can be made really generic – things like credit check, weather etc. For the rest, I think the standardization should be limited to a lower level – like consistent use of data types and lengths for widely used objects.

    1. Oliver Kling Post author
      Oh – that is a good illustration and I like it – however I wonder if one can not derive a different conclusion from it.
      Two questions come to my mind 1) what is the value of ‘type’ in the banking industry and 2) is the ‘market’ not rather an environment where ‘survival by the fittest’ is the rule of the game?

      Among the fittest banks I see those that can accomodate their business model very fast – that means low IT hurdles where I see at least a relation to standarization.

    2. Paul Centen
      Hi Vijay,

      I like your example as you indirectly point with “type” to skin/hair. Let’s consider “type” in the sense of ability and skills. The sled (husky), hunting, guide, sheep, safeguard dogs might look the same, but serve to different demands.

      That distinction can’t be made if one considers mammals and their differentiations.

      Coming back to banking: about 25 years ago engineering and construction industry behave similar to nowadays banking. Also they believed that unique selling points have to be embedded in their application software. Today, they collaborate on supply chains and reduce the complexity of production. Still Boeing and Airbus are different (and that not only from outside).

      Please have also a look in the series “Adoption of Trends”, here within Banking-BPX. Banking industry might save a lot of money without loosing differentiation among the banks. Similar to E&C in those days, it’s a leapfrog in mindset, but not impossible or feasable.

      Kind regards Paul

      1. Vijay Vijayasankar
        One distinction might be to divide all services into two large buckets – one bucket that offers competitive advantage (probably what a particular bank does different / better than others – probably some customer facing functionality) and another that has all services that every bank needs (like clearing checks, read account balances etc).

        The idea being – the second bucket is a great candidate for across the board standardizing.

        1. Oliver Kling Post author
          Maybe it is not only two buckets but additionally a question of the detail of standards.
          One could call it a “half standard” or something like that. Which defines a consensus on a somewhat abstract level but leaves more or less room to provide a unique selling proposition. E.g. defining only mandatory attributes (“must understand”).
          1. Vijay Vijayasankar
            agreed – details of a standard is an important qualifier. But the problem is that if it is a half standard, it is not easy to commoditize it for all banks. Anything that is a half standard is probably a more a fit to the USP bucket 1.

            But then again, the devil is in the details. If we can standardize the way USP is implemented – may be that will do. In a simple case, it might mean that all enhancements after the mandatory fields have some kind of unique tag to identify them.

            1. Oliver Kling Post author
              Yes that sounds reasonable – there is additionally another possible view: If we think in terms of consumers or providers one can look at the border inbetween the two, which can be seen as an abstract component border. This in mind it might make sense to have a common understanding about the major components ‘only’, that is if we have agreed the major components we probably have supported the semantic integration as well (viewed from a different angle – of course).
              1. Vijay Vijayasankar
                An abstract layer helps – I can see that.
                However consistent abstraction comes at a sizeable cost to ISVs, and unless something like EDIFACT is available for services, every vendor will choose a different abstraction that kind of beats the purpose.

Leave a Reply