Here is the SOA 1.0 approach to customer self-service.
- A simple standard "one size fits all" service for all but the best customers.
- Use self-service to strip cost, risk and complexity from customer-facing aspects of service provision.
- Exploit economics of scale in back-office service provision.
- Outsourced or offshore provision is adopted for cost reasons alone, regardless of its effect on the quality of service.
- Low trust - reliance on simple security technologies, used mainly to protect the service-provider from expense and liability
- Customers treated as if they were stupid, lazy and/or dishonest.
- Each customer can compose services according to the context of use.
- Each customer can customize processes and policies.
- Customer groups can self-organize and develop composite services for their members.
- Rich and productive service-based interactions result in higher levels of trust.
- Deep support for the long tail.
The authors argue that there is a huge potential wasted value locked up in these dysfunctional service relationships. They advocate a form of deep support, that will release/realise what they call relationship value, and they paint an attractive and detailed picture of the way it might work.
Roman Rytov offers a simple example of what deep support might mean, when he comments that his favourite grocery store has the ability to analyse his purchasing behaviour, so he'd like access to the data as well.
Wouldn't it be a great idea to provide me detail statistics on what I've bought, how much I've spent on certain categories, what was my price deviation during a certain period, how I could plan my food budget, and so on, and so forth. ... For me this service would be a meaningful differentiator.
Here's another example. If the banks trusted the honesty and intelligence of their customers, they could allow the customers to help define the transaction policies governing their bank accounts. At present, my bank only offers me two options for online banking - Yes or No. Suppose I want the convenience of online banking - but only for small payments to known recipients. For large payments to unknown or foreign recipients, I am happy to incur the inconvenience of a personal visit to my branch, to eliminate (or at least greatly reduce) the possibility of impersonation. I should like to be able to write my own transaction security policy, in a standard policy language. which would be automatically executed by the bank software in addition to its own security policies for all attempted transactions on my account. Note that if lots of customers take advantage of such a facility, the consequent diversity would make fraudulent attacks very much more difficult, and this in turn makes everyone (except the fraudsters) safer.
Many of the technologies to support SOA 2.0 already exist. For example. rules engines that govern service execution dynamically, according to policy and context. For example, business intelligence tools that allow complex enquiries to be rendered as web services. And of course many of the same technologies that support Web 2.0.
But many service providers are still reluctant to grant customers access to these tools. Perhaps they will not act until some "killer demand" emerges that will force them to respond to the real needs of the customers. In the meantime, how long are we consumers going to have to put up with poor service, poor security, poor value?