Economics of Style

In his latest blogpost, Fine-Tuning the SOA Maturity Model, David writes:

"Time and again we recognize that a scope based approach to maturity is the most useful determinant of maturity that decomposes well to each of the stream views because services are increasingly useful as they are used more widely, and conversely expanding the SOA scope beyond traditional organizational boundaries is without question the hardest thing to achieve."

In a fascinating recent paper, Chunglin Kwa identifies two contrasting perspectives on complexity, which he calls "Romantic" and "Baroque". From the Romantic perspective, complexity increases with scope (emerging from the increasingly stormy and ambitious interaction between diverse elements); from the Baroque perspective, complexity increases with detail and specificity (emerging from the increasingly precise delineation of fractal elements).

David is quite right to indicate the difficulty of expanding the SOA scope beyond traditional organizational boundaries. I have spent a lot of time talking about this myself. But I don't think this is the only kind of difficulty/complexity we need to address, and I should not like just to equate maturity with ambition.

Reference: And if the Global Were Small and Non-Coherent? Method, Complexity and the Baroque (pdf) John Law, Centre for Science Studies, Lancaster University, 2003.

See also my Squidoo lens on Baroque Style.

Grey Matter

One way to get greater economics of scale (and scope) in SOA is to simplify and generalize the basic services by shifting some of the complexity into the wiring between the services.

So I was interested to hear a report on the radio today about recent studies of the human brain. As I understand it, the brain is divided into grey matter (which does the basic thinking) and white matter (which wires everything together). So perhaps we can very crudely equate the grey matter with services, and the white matter with the orchestration of the services.

Now here's the interesting bit - the ratio of white matter to grey matter in different people. Pathological liars have significantly more white matter than other people. (It seems that skilled falsehood requires greater orchestration. It is not clear whether people lie because their brains enable them to lie, or whether some brains develop in particular ways because their owners are exercising the capacity to lie.)

Meanwhile, autistic people tend to have a much lower amount of white matter than other people. There are two characteristics of autism that may be relevant here: difficulty in interoperability, and difficulty with anything other than the literal truth.

Has all this got anything to do with SOA and BPEL? You decide.

Source: BBC Radio 4, Leading Edge, March 16th, 2006
(full programme available online for a week after broadcast).

Technorati Tags: SOA service-oriented

Context-Aware Services 3

Paul Miller replies to my second post on Context-Aware services, and asks if this just means advertising. That's a good question, because most of the examples look that way.

My view of context-aware services is that any aspect of a service may be differentiated according to context. The service I get from a supermarket is fairly simple, so perhaps there isn't much scope for variation. But each customer may get a different set of special offers, and this can be generated dynamically, according to the contents of the shopping basket or the path through the store. A customer with a known taste for raw eggs, or a history of returning stale products, may get a warning that a selected product is close to expiry. But is that all? If all we're talking about is commodity advertising, then there is possibly no difference between selling soap powder and lending books.

But I'm not particularly interested in libraries selling me nappies, because I don't think that's their job. I'm interested in ways that the library can serve me better (not just target me better) through an awareness of my context. This is intrinsic differentiation - in other words, differentiation that is relevant to the service in hand.

For example, my son has just done a school project on a mathematician of his choice. He chose Florence Nightingale (the inventor of the pie chart). If he had gone into a library for help, would he have been offered a scholarly history of the Crimean War or a academic thesis about mortality statistics and their graphical representation?

Can a computerized system offer anything approaching the sensitivity and common sense that we still expect from a human librarian? At one extreme, there are standardized search systems, that will give you exactly the same answer whether you are a schoolchild or a BBC researcher or an LSE postgraduate. At the other extreme, there may be inflexible classification systems that assume that a child is only interested in reading books that are designated suitable for that age group.

One of the most important aspects of context is how the service fits into what the consumer (the customer, the library reader) is trying to do. Do I have an essay or article or thesis to write, and when is it due? Am I reading Nietzsche because I am learning German, or because I am learning existentialism (or both)? Am I reading Bede because I am studying history or historians (or both)? Does it make sense to read Locke without also reading Hume? What stage of my learning have I reached? Do I need an edition with glossary, with scholarly notes, with English translation facing? What is my preferred style of learning, my preferred style of researching a topic? Surely questions like these are relevant to improving the service offered by a library to a particular reader?

Ultimately, context-awareness takes us down a path of embracing user diversity. Not just user semantics, but user pragmatics. How much of the reader's context can the library possibly deal with, and what other service providers might the library collaborate with? There are some seriously complex models here.

I see context-awareness as a very significant challenge - introducing modes of complexity that most organizations have never dealt with before - but with the potential reward of offering massive improvements to the experienced quality of service.

Technorati Tags: context presence SOA service-oriented

Simplicity and Complexity

According to Bob Balahan (3C-InterOp), web services are not there (yet). He argues that the interoperability promised by web services is currently frustrated by the behaviour of the leading vendors. Here is my attempt to summarize the argument (which starts in his blog and continues through several replies to my comments.)

1. Web service standards are incomplete, open to multiple interpretations and implementations. (This is a form of leaky abstraction.)
   
2. As soon as you want to do something complex, you are faced with inconsistencies ("subtle differences") between different vendors. (And not just different vendors. With large and complex software coming from large and complex vendor organizations, and with consolidation occurring (and likely to continue) among the platform vendors, it would be amazing if there weren't sometimes subtle differences even within a single platform from one vendor.)
3. Obviously there is an incentive for developers who care about interoperability to identify and avoid the areas of inconsistency wherever possible. Where there is a threshold of complexity above which the differences between (or even within) platforms start to bite, developers should strive to remain below this threshold (thus getting interoperability despite the differences in interpretation and implementation above the threshold). Bob calls these "lowest-common-denominator features", known to work reliably everywhere.
4. Karen Hobert adds that the standards themselves are subject to change . She doesn't say this, but this is perhaps especially true in the areas where these inconsistencies have been identified. So complexity doesn't just affect interoperability but also maintainability.
5. However, remaining below the complexity threshold would be hard enough for developers who hand-coded everything. But when you use the code generation tools, you are taken above the complexity threshold by default. Bob and Karen have a nice example of this, where WSAD generated complex objects into the XML.

Bob sees all this as vendor lock-in. They could agree, he says, but so far they haven't. Who creates this complexity? Who benefits from complexity? The vendors.

---

There is certainly a tendency for complexity to escalate, and the vendors don't do enough to contain complexity, or to protect their customers from the consequences of complexity. But the benefits of this complexity to the vendors is unclear.

And I think we must give the industry some credit for what it has achieved to date. The situation used to be a whole lot worse than it is today. There may be specific areas where the standards let you down - but that's better than having no interoperability at all. And the point of a good architecture is that it should allow you to contain and manage the complexity and uncertainty.

---

See also Lost In Translation: Top Ten Tips for Web Services Interoperability
See my note on Code Generation