A theoretical, upper bound, value function for an SOA

Jeff says Metcalf. I say Reed.

The trick is to design services so that they can be actors in a wide variety of groupings (business processes).

This is tough. It requires a lot of experience and the ready availability of serious domain knowledge.

Good service boundaries do not "drop" out of decomposing discrete IT systems. They drop out of decomposing the "social network" that underlies a family of business processes. Decomposing the social network is mostly an empirical science:

• You need to put in probes and monitor traffic flows as they are, not as some ex-post facto Visio diagram claims they are and not as users (each of whom have their own complexity-reducing simplified mental models) tell you they are


• You need to hunt for simple repeating patterns in the apparent chaos of cross talk. I find it useful to do this anthropomorphically in terms of speech acts


• You need to find the feedback loops. They exist in any complex system and are the key to unlocking any underlying simplicities that are key to tractable implementation


• You need to find the key "nodes" in the power law distribution that governs (trust me) the connect-ness of the services network. In fact, I'd go so far as to say that if you do not get a power law distribution staring back at you from your analysis, repeat the analysis.


• Finally, you need to be lucky. The more detailed your emperical analysis is, the luckier you will be with your final services decomposition :-)

(lamb (type mutton)) or should that be lambda?

The details of the trends and transients day at the XML Summer School in Oxford has been posted.

I will be talking about stews, instance variables, sichuan peppercorns, pipelines, pythons, directed graphs, ducks, steganography, compilers, semantics, chameleons, containership relations, cardamon pods.,,and relating it with highly tenuous logic, to practical applications of XML.

Clarifying SOA

In this post on SOA, I am of course referring to the term "SOA" - the acronym. It has become, sadly, meaningless through lack of industry consensus.

This is not to say that what I consider to be an SOA is DOA. Far from it :-) However, I do find myself searching for an alternative term for it these days because the SOA term has become diluted to be point of content-freeness.

I've written about the bits that I believe are criical to make the term SOA mean anything in the past. In ultra summary form:

• Services are business processes that exchange documents to get their work done


• The document exchange is temporally decoupled.


• The documents have shared semantics expresed in a combination of human (narrative) and machine readable (XML) form.


• Documents express business level intent. For example, "Here is a purchase order" rather than "add_purchase_order(...)".


• Services are "connected" via protocols for asynchronous document exchange, not for synchronous functionality invocation.
  

Close up picture of my house

Screenshot
Originally uploaded by PropylonSean.

Here is a close up picture of my house from the inside. I've only just moved in so, excuse the mess. I'm happy with the way its shaping up.

Conversion culture

"Conversions of one form of digital data to another form of digital data are simply not, by and large, formulaic. -- The conversion culture of computing

Emacs on Ubuntu - Copy/Paste horrors, term mode delights

Emacs is like a laser guided missile. It only has to be slight mis-configured to ruin your whole day.

Copy/Paste does not play well with Gnome desktop on Ubuntu by default. You have to experience a borked copy/paste setup to appreciate how insanely frustrating it is.

Some horse whispering is required in your .emacs file:

(menu-bar-enable-clipboard)
(setq x-select-enable-clipboard t)

Thanks to Anders Carlsson for posting how to do this.

What a relief!

On the delight side of the equation, term mode allows me to have colored bash shells in Emacs. Very pretty.