Personalized emails (not)

Here's a sample from my email inbox, which arrived yesterday.

Dear Richard
I know how important your organization's big data strategy is. That's why I want to personally invite you to attend our webinar. 

How does he know? Is he basing his knowledge on big data or extremely small data? I'm curious to know which.

And what is his idea of a personal invitation? Does he think that personalization is achieved by having his email software insert my first name into the first line? Gosh, how very customer-centric!

But at least the email arrived at a civilized time. Unlike the one that arrived as I was getting into bed the other night, from an eCRM system whose idea of personalization didn't extend to checking what time zone I was in. I guess one must be grateful for these small mercies.

The Bits Stop Here

One of the drivers for SOA, both commercial and public sector, is to extend and enrich the opportunities to provide services to customers/citizens over the internet.

But the more reliance we place on electronic identity, the more important it seems to be to link this back to some face-to-face identification by a trusted authority. And these processes are getting more tedious. Perhaps rightly so, as identity theft becomes ever easier and more prevalent.

For example, before I could open a savings account for my son recently, I needed a lengthy interview with a bank clerk, who apparently needed to take photocopies of my passport and utility bills. This routine is called 'Know Your Customer'.

[Wikipedia: Know Your Customer]

It's not good enough for the bank clerk merely to see these documents. A paper archive is needed for "compliance" - in other words, providing retrospective evidence that I haven't tricked or bribed the bank clerk to overlook some missing document. Is this because the bank doesn't entirely trust its own employees?

But the bank does trust the paperwork from other organizations with which it has (as far as I know) zero electronic interoperability (the passport authority and the utility companies). That's nice.

Until recently, UK citizens have been able to apply for passports remotely, but the Identity and Passport Service is going to introduce face-to-face interviews. At which I guess we are going to produce copies of bank statements and utility bills.

[BBC News: Interviews for passports 'vital', Robin Wilton: Face-to-face interviews for passport candidates, Tomorrow's Fish-and-Chip Paper: And talking of the Identity and Passport Service ...]

Meanwhile, the utility companies are trying to back out of this role in the network of trust, by producing electronic bills instead of paper ones. These are useless for identification purposes, because they can be too easily forged by amateurs. (Forging old fashioned utility bills does require a tiny amount of expertise.)

So there seem to be some infinite loops in the network of trust, with some pretty obvious vulnerabilities yielding countless opportunities for real crooks.

I was minded of this when I saw the problems faced by Tim Bray getting a new Canadian passport. Spent nine hours waiting in line.

[Tim Bray: Passport Hell, Emerging Chaos: How Long to Be Identified]

Maybe electronic identity (complete with biometrics and RFID) is going to save you a little time for each transaction, but if it takes that long to get/issue the credentials in the first place, then there is some catching up to do.

As it happens, there are some pretty bright people in the IT industry working on exactly this problem, and some pretty neat solutions emerging. But the managers and politicians running the organizations that actually handle identity on a daily basis (leaving sackloads of unshredded personal data on the sidewalk, losing laptops on a regular basis, that kind of thing) don't seem to have a clue about this, don't seem to realise that they are just making things worse.

Like I said, there is some catching up to do. SOA (with Identity 2.0) has the potential to solve a lot of problems, but the first step is for the people who are causing the problems in the first place to acknowledge that they need help.

Otherwise all these cool solutions will just remain interesting talking points for bloggers.

Value Deficit

Roman Rytov has blogged before about services from the consumer perspective. (For example, my previous post on Self-Service draws on his ideas about customers having access to their own CRM data.) In his latest post, he blogs about flaws of frequent flyer programs and sensitivity to customer needs. He points out that the standard reward point program, as provided by airlines, hotel chains and other service providers, is no longer working. It doesn't provide real competitive advantage to the service provider, and fails to accommodate the needs of different categories of customer.

For many customers, one of the most important differentiators is between private travel (where the customer is paying) and business travel (where someone else is paying). Rytov imagines (probably correctly in most cases) that private travellers would prefer to receive compensation for delays or other service shortfalls in the form of a cash refund ("the internet in your room was a bit slow - okay we'll delete that item from your bill"), while business travellers would prefer to receive extra airmiles or reward points.

But how is the service provider supposed to differentiate between private travellers and business travellers? I don't think this is as easy as Rytov asserts, and I don't think it should be that easy. Am I flying to Las Vegas for a business conference or a weekend of excess - and do I really want this to be public knowledge? Surely the best approach is to allow the customer a choice between alternative compensation schemes, rather than try to second-guess the customer's preference based on an attempted invasion of the customer's privacy.

But there are larger problems with the whole pseudo-economy of reward points, which this kind of differentiated service will not address.

• The schemes are complicated, with all sorts of arbitrary restrictions, making it practically impossible to compare like with like. Benefits are tied, and are generally not transferable. This increases the transaction cost, and reduces the economic efficiency of the market. This exemplifies a general pattern of dysfunctional service relationships - see review of Support Economy on this blog.

• The schemes are closed. Given that there is a value deficit, there is a theoretical opportunity for an independent service provider to create some value-adding services, perhaps through some kind of mash-up. But something tells me that the airlines and hotel chains would be less than enthusiastic about such innovation; and I doubt that the schemes are open enough to make such mash-up feasible.

• The schemes are primarily designed to reward employees, ultimately at the expense of their employers. I am sure there are lots of people who take extra business trips, with questionable value to the business, in order to win or retain some privileged status with the airline. Therefore the whole economy of reward points and airmiles only appears to be value-adding if you ignore the companies that are ultimately funding it.

Of course SOA thinking (such as differentiated service or context-based service) can be used to put sticking-plaster on the current schemes. Rytov is correct as far as he goes - service providers certainly need to be more sensitive to customer needs. But I believe there is an opportunity for much more radical and genuinely value-adding transformation.

• Can we unbundle the services? Why am I paying the hotel for the internet connection? Why isn't the hotel just providing me with a platform of services, from which I can compose my own experience? Who pays whom for what?

• Can we decouple the services from the reward point program? Surely there are economies of scale for the providers, as well as increased flexibility for the consumer, if reward points are transformed into some form of exchangeable token. Especially as the reward point program has long since ceased to be a focus of innovation or competitive advantage, and has become a tiresome necessity.

Online Customer Experience

A new report on the Online Customer Experience by the consulting firm Keane (via Lorraine Cosgrove at CIO Magazine) confirms what I've been saying for a while - that most of the financial sector is not yet ready to embrace the more radical opportunities represented by SOA (what I've been calling SOA 2.0).

[This comment is currently based on the press release. I'm looking forward to reading the full report.]

In the Keane survey, companies in the financial sector were invited to classify themselves as Innovators or Contenders. It turns out (surprise, surprise) that those who believe themselves to be Innovators are spending more on SOA technology, while those who see themselves as Contenders are devoting their IT budgets to bigger and faster databases and suchlike.

But what exactly are the self-styled Innovators spending their SOA dollars on, and are they using SOA to produce genuine innovation in the customer experience? The Keane report mentions technological innovations such as Macromedia Flash and Flex, but I wonder whether these technologies are being used to deliver qualititatively different services to customers, rather than mere gloss?

According to Keane, nearly 50% of all respondents cited existing legacy technology platforms as the number one obstacle to improving the online customer experience. I am inclined to a more cynical view, which is that most of these organizations are still highly resistant to any radical thinking, and are still trying to use the new technologies to push the old business models. Don't blame the legacy systems if most of the obstacles are in the legacy organization.

To my mind, the challenge for the financial sector is to provide a flexible platform of heterogeneous context-aware financial services, from which the customer (or customer service adviser) can compose (orchestrate) a personal financial solution, subject to user-defined policies, to fit a particular customer context. [See my discussion on User-Defined Policy on the Asymmetric Design blog.]

Keane has produced a Service Maturity Model (yes, another one), and sees the Portal as the highest level of service maturity. So does this kind of flexible platform count as a portal? Perhaps it does, but it's a good step beyond the aspirations of most of the portal projects I'm seeing at the moment - whether in the financial sector or elsewhere.

If any of Keane's Innovators are working on this kind of thing, I'd be delighted to hear about it. (But if you're not, perhaps you would like me to come and have a quiet chat with your management team?)

Technorati Tags: SOA service-oriented

Joined-Up Government

Robin Wilton collected these trophies of Joined-Up Government at an e-Government conference in Manchester.

Robin Wilton's New Friends

I've been meaning to blog about Joined-Up Government (J-U-G) for a while now, and this just gives me a final nudge.

---

There have always been several different notions of J-U-G in play (as I have written before). I think it's particularly interesting to distinguish between an internal (service-provider) perspective and an external (citizen, service-consumer) perspective.

Internal Perspective

Governments can use SOA to connect within or between large departmental silos. There are enormous potential benefits in efficiency and effectiveness, which indirectly benefit the citizen.



But internal joining-up is only half the story ...

External Perspective

... and this is an example of what joined-up government looks like from the citizen's perspective.



Applying for a student place and applying for a loan are part of the same process. If government doesn't allow the citizen to synchronize these steps, then the citizen is forced to bear extra risk.

Joined-up government is then a way of improving service and reducing risk from the citizen's perspective as well as from the government's own perspective.

My CBDI Journal article on this topic is in the pipeline. Meanwhile, you may wish to look at an earlier article of mine on Joined-Up Services (2002).

Technorati Tags: government joined-up SOA service-oriented

SOA 2.0 Reaction

Not surprisingly, my proposal for SOA 2.0 has received a mixed reaction. So far I have received email from Iona, Microsoft (x3) and SAP, and I have detected relevant bloggery from John Hagel and Bill Eisenhauer. Simon Bisson offers an alternative proposal: Computing 5.0.

Let's start with the criticism first. (Some of this is drawn from emails, but I won't attribute specific remarks to specific people because I don't have permission.)

• Questions about the central importance of SOA. If you regard SOA as merely a (technical) means to a (business) end, then making a technological fetish of SOA 2.0 maybe doesn't make much sense. Some ongoing reservations about the nature of Architecture.

• Distaste for anything called 2.0. Mark Nottingham (BEA) chortles quietly in his blog.

• Suggestions that what I'm calling SOA 2.0 is already contained within SOA - this is what SOA is all about anyway. (See my earlier post on Ambiguity.)

I agree that there are some problems with calling anything 2.0, and I certainly don't agree with all the Web 2.0 hype. One of the main problems is the apparent implication than SOA 2.0 is some kind of product, a stepwise improvement on some other product called SOA 1.0. But the distinction I'm trying to make is not between two kinds of technological product but between two kinds of technological practice. SOA 1.0 represents a limiting (and to my mind relatively uninteresting) way of using SOA, while SOA 2.0 represents a bigger vision of what SOA makes possible.

Even if SOA is merely a means to an end, I have a strong preference for SOA 2.0, and I think I can construct ethical/social as well as economic/technological arguments for this preference. I don't have a naive belief that technology magically makes people's lives better, but I am cautiously optimistic about the potential for using SOA in ways that positively benefit people and organizations and improve the user experience. I have articulated one aspect of this in my post on Self-Service.

One of the problems of describing evolution is that the steps often seem artificial - the historian's problem of converting a continuous narrative into separate chapters / episodes. So of course SOA 2.0 may seem artificial. When I describe a management roadmap or maturity model for achieving the full potential of SOA, I can describe several smaller steps. But although such models are useful for planning and managing, they are not so good for communicating the vision.

So here is my appeal to SOA experts - vendors, users, consultants and industry analysts. Let us acknowledge that there is a great deal of useful technical work going on, but admit that much of this work lacks the elements that make SOA genuinely worthwhile and exciting.

So what are these elements? Here are some of the echoes from the emails I have received. (Obviously this doesn't represent a complete set of anything,)

• Yin/Yang - service consumption/service delivery, inside/outside 

• Collaborative - user-centric, federated identity, federated data 

• Pervasive - service-oriented, pervasive workflow 

• Presence - integrated user experience, operationally aware

• Out of Control, Emergent - uncontrolled reuse (in other words, reuse that is not constrained by the preconceptions of the provider, permitting hacking)

• Accountable - model-based, trustworthy

Self-Service

In my previous post, I talked about the difference between SOA 1.0 and SOA 2.0. In this post, I want to explore how the difference works by looking at Self-Service.

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.
  

But SOA 2.0 offers a much more attractive alternative - mass customization for the service economy. For example:

• 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.
  

There can be little doubt that the quality of service we experience as consumers is seriously lacking. One of the most eloquent books I have read on this subject is Support Economy by Zuboff and Maxmin. Here's an extract from my review in this blog.

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?

SOA 2.0

There has been renewed discussion of Web 2.0 around the blogosphere this week. Tim O'Reilly posted a schematic diagram Web2MemeMap onto Flickr, and published a long article What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software on his website. Several of the blogs I read have linked to either or both of these, and some of them have copied the diagram.

Many of the elements of Web 2.0 are highly relevant to service-oriented architecture and the service economy. In this post, I want to extract two sets in particular.

Loosely coupled systems of systems	Small pieces loosely joined - web as components Granular addressability of content Software above the level of a single device Radical decentralization
User-centric	Users control their own data Rich user experience Trust your users Emergent - user behaviour not predetermined Customer self-service - enabling the long tail

If we apply this kind of thinking to SOA, a distinction emerges between SOA 1.0 and SOA 2.0.

SOA 1.0	SOA 2.0
Supply-side oriented	Supply-demand collaboration
Straight-through processing	Complex systems of systems
Aggregating otherwise inert systems and providing some new communication channels	Frameworks, applications, agents and communication channels understanding each other more deeply. Building a smarter stack and designing applications to take advantage of new constructs that (we hope) promote agility and simplicity.	Erik Johnson via Dion Hinchcliffe
Single directing mind	Collaborative composition
Controlled reuse	Uncontrolled reuse	See my earlier posts on Controlling Content and Shrinkwrap or Secondhand
Endo-interoperability (within single enterprise or closed collaborative system)	Exo-interoperability	I am currently preparing a longer paper on interoperability and risk. See my recent posts on Efficiency and Robustness.
Cost savings	Improved user experience	This is one of the areas where SOA starts to get interesting for the business and not just for the technologists.
	An emerging network-centric platform to support distributed, collaborative and cumulative creation by its users	John Hagel

There are some other elements of SOA 2.0 that I intend to discuss in subsequent posts.

Service-Oriented Business Strategy

A service-oriented modelling approach helps us to identify alternative business strategies, involving the creation and deployment of added-value services.

• Identify value-added business services that can be seen (by customers) as more relevant to the context of use. 
• Identify value-added business services that are flexible / reusable (by customers) in multiple use-contexts. 
• Compose value-added business services in an efficient and reliable manner from internal and external capabilities. 
• Provide a service platform to support customers in composing our business services to solve their problems. 

I am in the process of defining an extended example from the pharmaceutical sector. The first part will now be published by CBDI in May 2005.

Why Pharma?

We selected the pharmaceutical industry for a worked example because it provides a good example of a complex information supply chain. A drug company (in collaboration with a distributed network of research and test) produces a drug, together with lots of information relating to the drug. There are several different categories of information user: the patient who takes the drug, the medical practitioner who prescribes and/or dispenses the drug, the health service or insurer that pays for the drug, and the regulator who monitors the safety of the drug.

Pharma appears to illustrate some general characteristics of complex service networks, so this example should be of relevance to other industry sectors.

Above all, for SOA illustration purposes, pharma has two advantages. Firstly, it isn't the same old boring examples everyone else is using (finance, travel, retail). And secondly, it isn't military.

In the past, drug companies have been able to make substantial profits from an essentially drug-centric process, getting high sales volumes for its blockbuster drugs from a largely undifferentiated mass of patients with a given condition. This business model treated the physician or clinic as pretty much equivalent to a retail outlet, and did not involve any relationship with the end-customer (the drug consumer). But this business model is subject to major challenge from several directions.

Approach

We model a business as an open system, whose viability depends on robust and appropriate interactions with a dynamic environment. (This contrasts with the closed system approach adopted by many traditional business modeling methods, whose focus is on producing a complete and coherent account of some internal configuration of processes and services, against a fixed view of the environment.)

We model a service-oriented business as a system of systems. Services here may include tasks automated in software (typically but not necessarily rendered as web services) as well as human tasks.

SOA is not just about decomposition – producing fine-grained services with maximum decoupling. Equally important is to think about composition – how these services can be integrated in many different ways to support a wide variety of demand.

In general terms, there are a number of distinct categories of stakeholder, each performing fairly complex functions in relation to the pharma value chain. A key SOA challenge for a drug company is to provide services to all these different stakeholders in a consistent and coordinated yet flexible way. In order to meet this challenge, we need to produce a series of models, from different stakeholder perspectives, showing how the services can be composed in various contexts of use.

In our view, the essential shift for service-oriented modeling is to view the services, not from the provider's perspective, but from the customer's perspective, and in the customer's context of use.
 

Strategic Reframe

From the perspective of business strategy, what we are looking at here is a strategic reframe of the pharma business. What is the drug company actually selling, and to whom? How does information and services become an integral component of the overall product offering?

The ultimate source of value for the patient is defined in terms of health. The provision of health to patients is based on the deployment of complex medical knowledge by a physician, and this in turn relies on information about particular drugs and combinations of drugs from the drug company and elsewhere. This essentially defines a value ladder, in which the value of the drugs contributes to the value of the heathcare.

While this kind of strategic reframing is widely discussed, what service-oriented modeling provides is a systematic way of determining and analyzing the strategic options, in terms of the value ladders that can be supported.

Can the drug company solve all the problems of healthcare? Can the physician solve all the problems of healthcare? The answer in both cases is of course NO. There is huge complexity involved, and the design goal for SOA is to define a reasonable separation of concerns between the physician and the drug company, that allows each of them to manage an appropriate part of the complexity.

---

Previous Post: SOA Pharma

Retail Tagging

In order to maintain some kind of control over the Veryard household finances, we resolve to monitor how much we spend in different categories. These are of course our private categories, and do not necessarily correspond to the categories defined by the retailer. For example, we buy lots of books; some of them are intended as birthday presents, some of them are for the children, some of them are work-related, and so on. One category: Christmas Presents; another category: School Requisites.

At the end of the month, we get statements from the bank and from various shops, showing the amounts spent using several different cards. Translating these data into a more useful form is tedious - it requires a combination of recollection, receipt-shuffling and manual data entry.

What I'd like to be able to do is attach categories onto each item at the time of purchase. My monthly statements from the bank and other service providers will come in XML format, with all transactions broken down using my own categories and ready to be imported into a spreadsheet or accounting program. Surely with the explosive growth of tagging this facility shouldn't be too far off now?

The retailers will no doubt be delighted with the extra data; it will give them access to another level of meaning over our purchasing behaviour. Meanwhile, traditional banks will be horrified by the cost and disruption to their antique systems, and may well resist any innovation.

Did I say monthly? Make that real-time please. I want all my service providers to populate my personal data warehouse (on some server somewhere, permanently linked to my Blackberry, with appropriate BI tools thrown in), using my own tags and alerts.

From the demand-side perspective, this sounds too good to be true. What makes it radical (and therefore probably hard for the supply side to comprehend, let alone implement) is that it puts the user (and context of use) at the centre of the service environment.

Most service providers put themselves at the centre. This is a vending-machine metaphor of service: the user puts in some coins, makes a selection, and gets a bar of chocolate. We can specify the behaviour of the vending machine as a series of use cases, and design a system from these use case specifications. But this design approach (which is very common, not only among SOA methods) is exclusively supplier-centric and develops no understanding of the demand-side.

(I am aware of the user-centric design movement, but this is often little more than user-centric interface design - in other words, website navigation, with no basis for a broader analysis of the service economy. And even this is strongly resisted by a supply-side-dominant software industry.)

Our approach to SOA modelling embraces the demand-side as well as the supply-side. At present, we believe this is unusual if not unique.

Update: I just found a post by Rebecca Dias requesting something similar. She wants some technology that saves time producing expense reports. There are some responses to this request in the comments following her post. But the categories on my expense form don't match the categories defined by the retailer. The restaurant receipt doesn't show whether I'm just having dinner on my own or entertaining a client, but this difference is important when I do my expense report. So I think some form of user-defined tagging is an important requirement here.

Rebecca Dias, iPAQ without a phone, why bother? (30 November 2004 via WaybackMachine)