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?
