Customer Multiple

A friend of mine shares an email thread from his organization discussing the definition of CUSTOMER, disagreeing as to which categories of stakeholder should be included and which should be excluded.

Why is this important? Why does it matter how the CUSTOMER label is used? Well, if you are going to call yourself a customer-centric organization, improve customer experience and increase customer satisfaction, it would help to know whose experience, whose satisfaction matters. And how many customers are there actually?

My friend's organization provides services to A, which are experienced by B and paid for by C, based on a contractual agreement with D. This is a complex network of actors with overlapping roles, and the debate is about which of these count as customers and which don't. I have often seen similar confusion elsewhere.

My friend asks: Am I supposed to have a different customer definition for different teams (splitter), or one customer definition across the whole business (lumper)? As an architect, my standard response to this kind of question is: it depends.

One possible solution is to prefix everything - CONTRACT CUSTOMER, SERVICE CUSTOMER, and so on. But although that may help sort things out, the real challenge is to achieve a joined-up strategy across the various capabilities, processes, data, systems and teams that are focused on the As, the Bs, the Cs and the Ds, rather than arguing as to which of these overlapping groups best deserves the CUSTOMER label.

Sometimes there is no correct answer, but a best fit across the board. That's architecture for you!

 

Many business concepts are not amenable to simple definition but have fuzzy boundaries. In my 1992 book, I explain the difference between monothetic classification (here is a single defining characteristic that all instances possess) and polythetic classification (here is a set of characteristics that instances mostly possess). See also my post Modelling Complex Classification (February 2009).

But my friend's problem is a slightly different one: how to deal with multiple conflicting monothetic definitions. One possibility is to lump all the As, Bs, Cs and Ds into a single overarching CUSTOMER class, and then provide different views (or frames) for different teams. But this still leaves some important questions open, such as which of these types of customer should be included in the Customer Satisfaction Survey, whether they all carry equal weight in the overall scores, and whose responsibility is it to improve these scores.

 

In her book on medical ontology, Annemarie Mol develops Marilyn Strathern's notion of partial connections as a way of overcoming an apparent fragmentation of identity - in our example, between the Contract Customer and the Service Customer - when these are sometimes the same person.

Being one shapes and informs the other while they are also different identities. ... Not two different persons or one person divided into two. But they are partially connected, more than one, and less than two. Mol pp 80-82

Mol argues that frictions are vital elements of wholes,

... a tension that comes about inevitably from the fact that, somehow, we have to share the world. There need not be a single victor as soon as we do not manage to smooth all our differences away into consensus. Mol p 114

Mol's book is about medical practice rather than commercial business, but much of what she says about patients and their conditions applies also to customers. For example, there are some elements that generally belong to "the patient", and although in some cases there may be a different person (for example a parent or next-of-kin) who stands proxy for the patient and speaks on their behalf, it is usually not considered necessary to mention this complication except when it is specifically relevant.

Similar complexities can be found in commercial organizations. Let's suppose most customers pay their own bills but some customers have more complicated arrangements. It should be possible to hide this kind of complexity most of the time.

Human beings can generally cope with these elisions, ambiguities and tensions in practice, but machines (by which I mean bureaucracies as well as algorithms) not so well.  Organizations tend to impose standard performance targets, monitored and controlled through standard reports and dashboards, which fail to allow for these complexities. My friend's problem is then ultimately a political one, how is responsibility for "customers" distributed and governed, who needs to see what, and what consequences may follow.

(As it happens, I was talking to another friend yesterday, a doctor, about the way performance targets are defined, measured and improved in the National Health Service. Some related issues, which I may try to cover in a future post.)

---

Annemarie Mol, The Body Multiple: Ontology in Medical Practice (Duke University Press 2002)

Richard Veryard, Information Modelling - Practical Guidance (Prentice-Hall 1992) 

• Polythetic Classification Section 3.4.1 pp 99-100
• Lumpers and Splitters Section 6.3.1, pp 169-171
  

SOA in an Offline World

There is a discussion on Linked-In entitled SOA in an Offline World. The discussion has a technical focus: What kind of technology architecture to use with unreliable or intermittent network communications. There are some design patterns that may support intermittent connection, such as decoupling and asynchronous communications, and these patterns may be appropriate in a range of situations including military and medical.

A broader architectural question is whether we can use layering to hide these technical issues from the business-facing services in the layers above. In an ideal world, we would have a disruption-tolerant service platform, and the core business services and applications can then operate as if we had perfect and permanent connectivity.

In the 1990s, Peter Deutsch and James Gosling identified Eight Fallacies of Distributed Computing - invalid assumptions that inexperienced designers make when designing distributed systems. See Arnon Rotem Gal-Oz and Paul Vincent (TIBCO). These include the assumption of perfect and permanent connectivity.

By the way, Tim Bass questions whether anyone nowadays suffers from these fallacies. I think he's got a point, but perhaps the problem here is in the word "fallacy". If you ask a designer if he believes connectivity is going to be perfect, he will almost certainly say no. But if you inspect his designs, however, you may well find that he has failed to allow adequately for imperfect connectivity. Not so much a failure of belief as a failure of attention.

So the important question here is - can we compensate for the imperfections of distributed systems by having a really clever architecture, supported by really clever technology, so that the applications can operate as if we didn't have any of the problems of distribution at all? Some people may well believe that to be possible, either now or in the foreseeable future.

I don't think it's so easy. I have long argued that SOA needs to embrace three-valued logic. If this is done properly, it would make the whole architecture disruption-tolerant, not just the underlying layers. We also need to understand how disruption-tolerance affects the behaviour of the whole business-facing system. Not just technology then.

Distributed Event Processing

Went to a good talk at the BCS SPA last week by Paul Vincent of TIBCO entitled "Advanced CEP and EDA - Why the buzz on Wall Street?"

• BCS SPA website
• Paul's summary
• Paul's slides (pdf)

I was particularly interested in Paul's emphasis on the distributed aspects of event processing.

• Distributed event source - "A series of produced items fails at various QA stages, and their common attribute was a storage location - Multiple suppliers for a subcomponent are reporting delivery delays"

• Distributed event cache - This is a key component of TIBCO's advanced CEP architecture

• Distributed event consumption (destination) - Delivering rich situation awareness to field operations. This is related to the military doctrine of "Power to the Edge".

At my prompting, Paul talked briefly and circumspectly about the use of CEP in the military. He averred that at present the military are mostly using hand-built event processing rather than commercial products (but see later comment by Tim Bass).

How Many Events?

Homeward bound, delayed in Zurich by the consequences of a crashed Boeing at Heathrow, Opher Etzion blogs On events in flight management. It seems to him "that more events related to flights happened relative to previous years".

For regular business travellers, the best thing we can say about a flight is that it was "uneventful". However good the catering, however large and comfortable the seats, however charming and sexy the air staff, none of this can make up for the inconvenience of delays or lost baggage. So when Opher counts the number of events, I assume he is referring to adverse events.

Of course there are countless events in flight management that are completely invisible to passengers - or even to the air crew - unless something goes wrong, and perhaps even then. In a distributed man-machine system, different parts of the system will be paying attention to different types of event, at different levels of granularity. (An air traffic controller deals with the event PlaneAwaitingLandingSlot; his manager deals with the aggregate event NumberOfPlanesAwaitingLandingSlotIsGreaterThanX.) We can think of this in terms of the architecture of attention - this calls for accurate modelling of events, leading to clear system design.

Furthermore, as Opher points out, there is an important distinction between attention (detection) and action. "In some cases ... the detection is very easy, the complexity is in the response." Last week, Opher apparently experienced a failure of response. "The captain told us several times that he is pushing them to send buses, but they are not responsive ..." It is often easy to blame Them, but it isn't always clear who exactly is responsible.

So the other challenge in designing complex event-driven systems-of-systems is to specify the architecture of response. There are many people and systems and organizations involved in flight management, and a complex event may call for a complex and collaborative response.

So is there a universal and homogeneous event model shared by all the participants in flight management? I don't think we can reasonably insist on this. Instead, we have to allow for some kind of amplification and attenuation - where different subsystems may have different event models, and there is some mechanism for translating and coordinating across these different models. I think this approach is more flexible, more robust, and compatible with loosely coupled SOA.

Scale and Self-Organization

Werner Vogels, CTO of Amazon, knows a thing or two about implementing large-scale distributed SOA. So it's worth taking seriously when he tells us that

"For any truly scalable agile environment, self-organization is essential."

In his post Reading References, he goes on to recommend some papers and books on scalability and self-organization.

• Richard Conniff, The Limits of the Alpha Male
• Steve Grand, Creation: Life and How to Make It

My own favourite book on self-organization remains Kevin Kelly's book Out of Control, now available online on KK's website. See also the entry on Self-Organization in Principia Cybernetica.

If we accept that self-organization can be effective for addressing some classes of complex problem, next step is to develop practical methods for engineering self-organizing systems. There are some promising research projects in this area, and there's a conference in Leibzig in September (SOAS 2007). I probably won't have time to attend the conference myself, but I shall look out for the proceedings. I wonder whether Amazon will be represented?

See also Werner Vogels on Scalability (April 2006)

Clouds and Clocks 2

Pat Helland regrets ...

Pat Helland has resumed blogging, having recently returned to Microsoft from a sojourn at Amazon. In his latest post SOA and Newton's Universe, he renounces the quasi-Newtonian paradigm of distributed systems to which he adhered for most of his 30-year career, and outlines an alternative paradigm with some resemblance to the Special Theory of Relativity.

The Newtonian paradigm of distributed systems is that we are trying to make many systems appear as the One System. This paradigm may be linked with the idea of the Global Schema or Universal Ontology. Helland contrasts this with an alternative paradigm of distributed systems, in which the systems are entirely dependent on the point of view of the observer, and there is no Universal Ontology. (I'd have wanted to use the term relativistic semantics here, but it has already been bagsied for academic linguistics - see for example Catfood and Buses.)

Helland sees this in terms of a relaxation of consistency. I disagree. Distributed systems-of-systems (including SOA) must follow a consistent logic - but not necessarily a traditional two-valued logic. Flexibility comes from being underdetermined (clouds) rather than overdetermined (clocks).

See my earlier posts Beyond Binary Logic and On Clouds and Clocks. See also Philip Boxer on Modelling Structure-Determining Processes.

Support Economy

Review of The Support Economy, by Shoshana Zuboff and James Maxmin
Viking Penguin, 2002.

---

This book is a detailed and persuasive account of the distributed service economy, which the authors call Distributed Capitalism. The background is familiar. An ever-greater share of Western economy is occupied with services rather than products. And yet our experience of service is generally bad - and getting worse. Service providers are trying to achieve economies of scale and cost-savings, while maintaining or increasing revenues. Service staff are under increasing pressure and scrutiny, and "empowerment" is eroded by targets and other narrow initiatives. Consumers are subjected to the indignities of call centres, the persistent nuisance of "courtesy calls", and the inflexibility of business processes that have been tailored to fit an internal corporate agenda.
The promise of eCommerce was that it would offer a genuine alternative for business and consumer relationships. With some honourable exceptions, this promise has failed. Many early eCommerce efforts were coloured by naivety and amateurism ("if we can get a small cut from every purchase made by every large manufacturer, we'll be rich, rich, rich"), or by cynicism ("if we can persuade our customers to do their own admin online, we can get rid of half our staff"). General consumer experience of eCommerce is poor - often because the service details (good logistics, prompt and effective troubleshooting, and so on) have been neglected. And what has happened to all those B2B portals?

What Internet shopping encourages is something the authors call ninja shopping. If a consumer can easily compare prices for flights or car insurance (but cannot so easily compare other characteristics, including service quality), then selection will be based on price, and prices will be driven downwards. Initially this seems to work to the consumer's advantage. But the providers retaliate with an increasingly impenetrable array of extras, excesses and surcharges, which aim to recoup profit margins while making accurate price comparison near-impossible. (I call this Complexity-Based Pricing.)

Consuming services becomes an incredibly time-wasting activity. You have to wait in line to hire a car, because the clerk is obliged to try and sell an array of options to every customer. You have to check-in hours before a flight, and you still may miss the connection. You have to review all service bills carefully for unexpected charges and other errors. You have to wait for everything. (This waiting is an almost inevitable consequence of traditional process thinking: if a customer ever gets immediate attention for anything, this rings alarm bells in the process office, indicating that the relevant function is over-resourced.)

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. They go on to argue that the realization of relationship value calls for a new enterprise logic: distributed, federated, dynamic, infinitely configurable; technologically supported by digital media and infrastructure convergence. From an SOA perspective, this sounds very familiar.

The book is not just an eloquent argument for the service-based business, but also a powerful vision of how it can and must be done properly. Recommended reading for everyone interested in the service economy.

Review first published in the CBDI Journal, July/August 2004.

---

The Support Economy Website

See also Shoshana Zuboff, Creating value in the age of distributed capitalism (McKinsey Quarterly, September 2010)

Related Post: Heartbeat Economy (January 2005)

Updated 14 May 2014

Contract First

A number of people are championing Contract-First Development within SOA.

For example, Aaron Skonnard of Pluralsight. In a number of recent blog postings on the topic, he reports a sympathetic hearing from Microsoft personnel (Bill Gibson, Simon Guest) and asserts support from Microsoft products (BizTalk Server). [August 27, 2004] [November 11, 2004] [November 11, 2004 (again)] [November 30, 2004]

But I am concerned that some people are basing Contract-First Development on a narrow notion of Service Contract - for example, equivalent to the signature of a service, expressed in WSDL. Sometimes people talk about Schema-First Development, which indicates a concern for semantics as well as syntax. But I don't think this goes far enough.

I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA. We have used the term Distributed Design-by-Contract to emphasise a broader concern for all these dimensions of a service contract.

Actually, I don't really mind which term we use, provided that we can assume the broadest meaning for the term Service Contract.

BPEL

At CBDI, we are generally supportive of BPEL. However, we do not see it as a complete solution to business collaboration. We have raised a number of issues over the past two years.

In business terms, the basis for collaboration between autonomous business entities is a service contract. This suggests a design process in which contracts are paramount - such as Design by Contract. One of our concerns about the web service stack (including BPEL) is that it lacks proper support for contracts and assertions. We proposed that service contract should be a first-class construct, and we have yet to be convinced otherwise. We look forward to seeing what emerges from WS-Choreography.

Secondly, we think the ideal of distribution or federation remains some way off. For example, while WS-Transaction supports distribution, BPEL assumes that the process management is hosted on a single engine, although there have been hints that a future version of BPEL will support distributed process management. In the meantime, some people are experimenting with alternative approaches to distributed process management, such as OGSA.

See for example Grid Web Services and Application Factories (pdf)

Thirdly, there appears to be a widespread assumption that the orchestration or choreography is established at design time, with only minor modifications (such as the introduction of new, interchangeable partners) at run time. In time we should progress to real time orchestration.

See CBDI Newswire 22nd May 2003 and 28th May 2003 (free access).

See CBDI Reports From Web Services to Web Collaborations (Nov 2002).