Loosely coupled intuition

Perhaps we should not even attempt to define loosely coupled. After all, if you need a precise definition, then you haven't understood the concept, which doesn't deal in detailed prescriptions. A loosely coupled system is one that consists of autonomous participants that interact with each other according to a shared understanding. The best analogies are not mechanical but biological and cultural.

Taking an analogy from management, I think the essence of loose coupling is effective delegation. It's about giving the participants in a process the tools they need to fulfil their roles as effectively as possible — whether they be individual people, teams, entire businesses, or automated systems. It is up to the participants to come up with the desired results, without having someone micromanaging their every move.

Another analogy is political. A liberal democracy is a loosely coupled society. We all trust each other to act within certain parameters. There are incentives and penalties that safeguard or compensate us in case someone breaks the rules, but by and large, everyone gets on with their own thing and it all works out in the end.

This human dimension means that you don't actually have to know the definition of loosely coupled to get it — you already know it intuitively. Earlier this week, Arnold Kling, who founded homefair.com in 1994, linked to my recent comments on John Hagel's definition of loosely coupled (mischievously labelling John as "a consultant who specializes in buzzwords"). Arnold makes some great comments, recalling a link homefair.com set up to Mapquest "over five years ago, before we had these new buzzwords to describe what we were doing." His conclusion illustrates this intuitive adoption of loosely coupled practices:

"I find it fascinating that Microsoft, whose Evil Empire is built on the buzzwords "tightly integrated," is now aggressively pushing something that seems to be the exact opposite. Other people may see something sinister at work, but I see it as simply reflecting that Microsoft's core strategy is to mobilize the best software developers.

"The best software developers are psyched about loosely coupled web services. And I didn't even know the buzzword until today."

posted by Phil Wainewright 1:03 PM (GMT) | comments | link

A long-term perspective on IBM

Likening business process integration to the struggles of dinosaurs in tar pits, CBDi Forum has taken geological time as a backdrop to its analysis of IBM's on-demand pitch last week. Writing in this week's edition of the firm's email newsletter, David Sprott makes pertinent observations, such as:

• "The vision is really long term. IBM ... is setting out a vision that is going to take decades to realize in full."


• "The vision is all about customer issues. Sun's vision is all about technology and quality. Microsoft's vision is about features and function. IBM alone is sharply focused on business process enablement."

His analysis also includes the most succinct summary I've seen so far of the four pillars set out by Palmisano of the IBM strategy:

1. Integration — components and services implemented with full separation and implementation transparency.


2. Open — all layers of the stack based on open standards.


3. Virtualized — not just location independence, but also a major focus on increasing the woefully inadequate resource utilization levels across the industry.


4. Autonomic — all layers of the stack operating as an immune system.

CBDi's thoughtful and informed analysis is kinder to IBM than my own ASPnews column this week. But I too was conscious of the backdrop of time, in my case looking back to Lou Gerstner's 1995 Comdex keynote, which launched IBM's commitment to what was then called "network-centric computing". I spelt out my suspicion that IBM is still largely mired (not in tar pits but) in a centralizing mindset:

"The true meaning of on-demand is a peer-to-peer model in which resources can be shared from anywhere on the network, and which has no definable center. As long as IBM perceives on-demand computing as something that its customers get from IBM, it will be imagining itself at the center of their network, and thus inevitably its products and services will fall short of its vision ... enterprises that want to exploit the full potential of on-demand computing should remain wary of locking themselves into Big Blue's Big Grid."

I'm sure IBM will argue its commitment to open standards demonstrates that it's no longer in the game of ensnaring customers with proprietary lock-in, and that much I'll agree. But when you move beyond technology infrastructure into the realms of process and culture, lock-in becomes more than purely a matter of systems architecture. Many outsourcing customers will bitterly attest to the power of service lock-in — and it is something that can be achieved using an entirely open-source platform.
posted by Phil Wainewright 3:04 AM (GMT) | comments | link

Finding a place for UDDI

Although UDDI is routinely cited alongside SOAP and WSDL as the third foundation standard of web services, it is both the least understood and the least often implemented of the three specifications. Its reputation has suffered by association with the grand vision of the Universal Business Registry, a naive attempt to establish a global B2B exchange for web services. Version 3.0 is more realistic in allowing for an interlinked hierarchy of both public and private registries, but remains appropriate only for larger or more complex web services environments, so implementations are still few and far between. (For more on UDDI 3.0, see The Stencil Group's white paper on behalf of UDDI.org).

When linking within a single enterprise, or between a restricted set of known partners, more established directory services technologies often make an attractive alternative. An eWeek feature this week looks at Microsoft's upcoming release of AD/AM (Active Directory in Application Mode), which can manage non-Windows resources, while a companion article compares it to non-Microsoft alternatives under the heading "Pure LDAP Servers Buoy Web Services." A third article, titled UDDI Spec Needs What LDAP Has, looks at efforts by vendors such as Novell and Sun to bolster UDDI with LDAP technologies, stating that "LDAP's strengths — which include maturity, reliability, scalability and security — are key attributes lacking in current web services standards."

Novell is one of the vendors pushing strongly to fuse UDDI with LDAP, for reasons the company's standards supremo Winston Bumpus explained to NetworkWorld in June: "If you look at the function of an UDDI registry, companies are going to write to it a few times and then read it a lot — which is exactly what directories are optimized to do. In addition, directories inherently support authentication mechanisms, adding security to the registry, and are extremely fast and scalable."

This seems eminently sensible, especially in view of the move in UDDI 3.0 to a more hierarchical model, which is exactly the type of data that directories handle best. But UDDI is based on a relational data model, as InternetWeek's Richard Karpinski discovered in the course of an article published in June. so maybe LDAP wouldn't make such a good platform for it after all.

Fortunately most web services implementations can afford to ignore these debates for the moment. UDDI still seems to be as misunderstood as it was in June, but there are plenty of alternatives, even besides LDAP. For linking between known parties, there's WS-Inspection, also known as WSIL (web services inspection language), which in a detailed article Timothy Appnel recommends for those who want a more "lightweight ... document-based approach."

But don't write off UDDI just yet. In an essay to coincide with the publication of UDDI 3.0 in July, leading Microsoft SOAP guru Don Box included this very intriguing comment: "If WSDL and UDDI were both hanging from a cliff and I could only save one of them, it would be UDDI."

UPDATE: When first published, this posting gave the impression that WS-Inspection and WSIL were two different specifications. Thanks to Timothy Appnel for promptly alerting me to the error, which I've now corrected.
posted by Phil Wainewright 11:25 AM (GMT) | comments | link

Swallowing your own web services medicine

Dozens of startups are vying for leadership in web services management, but the frontrunners all seem to have overlooked a crucial flaw in their proposition. Confluent Software is the latest to join the fray, and according to an analysis by the451 published by SearchWebServices today, its management aims "to position CORE as a complete package for web services management." If that's an accurate portrayal, then the company — formerly known as Corporate Oxygen — has fallen into exactly the same trap as its peers.

I can sympathize with the desire to offer a tightly integrated, comprehensive, end-to-end proposition. It's what enterprises have come to expect, and it's the right kind of winner-takes-all bravado to inspire confidence among your venture capital investors. But it's hardly in the spirit of a loosely coupled service-oriented architecture, is it?

Instead of looking for the web services management vendor with the most comprehensive solution, what customers really ought to be doing is seeking out the ones who are most open to interoperability with their competitors. Indeed, to criticize those competitors as "incomplete or overspecialized" could actually be construed as inadvertently praising them while displaying your own lack of empathy for the web services model.

I used to find a similar disconnect in the business models of some of the early ASPs, who sought to encourage their customers to outsource vital business software assets at the same time as boasting of the superiority of their wholly-owned, end-to-end infrastructure. It's never a good idea to build a logical contradiction into your core go-to-market proposition, particularly not when you're a startup in a newly hyped technology sector. Customers will find it difficult enough to swallow your medicine as it is, but if they see you following a completely different prescription for your own business, don't be surprised when they take their custom elsewhere.
posted by Phil Wainewright 7:57 AM (GMT) | comments | link

Implementing web services

Some useful advice from McKinsey and from ZapThink on best practices for implementing web services (thanks to Doug Kaye for highlighting both articles).

The McKinsey article (via CNET) is a characteristically clear and concise overview of why and where enterprises should be implementing web services today. "The best use of web services currently lies in applications in which connectivity problems are more complex, efficiency gains are greater in the near term, and alternative ways of connecting companies are limited." That is, at the edge of the enterprise rather than internally.

It also highlights the pitfalls and risks enterprises need to be aware of. It notes the importance of establishing shared business semantics ("Without precise definitions, the exchange of information can’t be automated") and emphasizes that companies need to adapt new ways of working: "It is management’s attitude that will ultimately determine who creates value with Web services."

The Zapthink article comes from last week's issue of the analyst group's ZapFlash newsletter. It provides further cautionary warnings to those who believe the best place to implement web services is as a quick patch to solve pressing integration bottlenecks within the enterprise (this is so good I'm going to quote at length, but there's still more that's worth reading in the original):

"The critical issue is the difference between using web services in a loosely-coupled, service-oriented manner, as opposed to misusing web services in a tightly-coupled, point-to-point manner. Vendors that pitch their wares as 'SOAP wrappers' or 'web services adapters' offer a dramatically short-sighted view of integration that seeks to lower only the initial costs without solving any of the fundamental problems of the traditional EAI/B2Bi approaches ...

"While it is true that the use of standards-based technology lowers initial and perhaps even configuration costs, these tightly-coupled web services adapters are just as brittle as the EAI adapters of old. Instead of having to reconfigure 300 DCOM or CORBA calls when a system changes, integrators will have to reprogram 300 SOAP calls. All they have done is play a shell game, moving the pea from proprietary to standards-based adapters. This approach doesn't do squat to loosely couple the systems or change their level of granularity."

One of the reasons why McKinsey finds its clients are having most success at the edge of the enterprise is probably precisely because this is where flexibility and loose coupling are at a premium, and therefore it never crosses anyone's mind to even attempt to 'pour concrete' over the processes in question. But as ZapThink's analysts point out, the service-oriented approach eventually needs to permeate throughout the entire architecture to truly realize the benefits of web services. You have to start at the edge, but you haven't finished till you have edges everywhere.

The ZapThink article coincides with publication of an updated edition of the group's excellent report, Service-Oriented Integration - Using Web Services and XML to Integrate Systems, available from ZapThink for $995.
posted by Phil Wainewright 6:29 AM (GMT) | comments | link