Police Radio

As technological interoperability improves, so we are faced with interoperability problems at a higher level.

The latest illustration of this comes in a story about the new UK police Airwave system, which provides a common communication platform for police forces across the country. It turns out that these communications are hindered by the use of regional dialects and accents, as well as local slang. Having spent £2.9 billion on new radios, the government will now spend an extra £25,000 training policemen to talk proper.

And more succinctly. It seems the system can't support long rambling conversations. NIPA, the government agency responsible for "improving" the police, worries that "regional phrases might take much longer to say than a clipped national term". Presumably the slow drawl of a rural policeman will have to be replaced by a rapid urban patter.

Technological interoperability should be taken for granted (NOT "a thing of the past", as I originally posted) - although the price tag for the Airwave system reminds us that significant investment is still required to achieve this. But technological interoperability is never enough - it merely creates the opportunity to start work on new modes of collaboration and interoperability at the semantic level.

Police Cautioned Over Loose Talk. Sunday Telegraph, June 17th 2007.

SOA Stupidity

In my previous post on SOA Chaos 2, I discussed Jeff Schneider's view that Stupid People Shouldn't Do SOA.

I've now been looking at Stephen Swoyer's article SOA Fatigue: It's the People and Processes, Stupid (ADTmag September 2005). He talks about several forms of stupidity affecting people, processes and organizations, which interfere with successful SOA.

• bureaucratic infighting, turf wars, petty fiefdoms
• incentive incompatibility
• inertia
  

In such a context, it is the collective intelligence/stupidity of the organization that matters. Inside stupid organizations, most clever people either try to protect themselves from the stupidity, or find smarter ways to exploit it to their own advantage. I think the Conmergence blog is wrong to try to blame SOA failure on stupid people.

But I don't think it's helpful simply to blame SOA failure on organizational stupidity either. I think it makes more sense to regard the problems discussed by Swoyer as problems of interoperability. And I think one of the implications of Swoyer's discussion is that interoperability is not just a technical question but a sociotechnical question (involving people, processes and organizations). Achieving (and motivating and funding) requisite levels of interoperability with SOA is a matter for SOA governance.

To those that have ... Organizational intelligence is both an enabler for effective SOA, and a result of succesful SOA.

Swoyer reports that Kareem Yusuf (director of SOA product management at IBM) advocates a strong top-down push for service-enablement. (Well he would, wouldn't he?) This approach might make sense for improving interoperability within one organization (endo-interoperability), but isn't going to help much with interoperability between separate organizations (exo-interoperability).

Technorati Tags: governance interoperability organization intelligence service-oriented SOA

Deconfliction and Interoperability

Deconfliction

Deconfliction is an important type of decoupling. In October 2001, a Time Magazine cover story (Facing the Fury) used the term.

Bush's gambit — filling the skies with bullets and bread — is also a gamble, Pentagon officials concede. The humanitarian mission will to some degree complicate war planning. What the brass calls "deconfliction" — making sure warplanes and relief planes don't confuse one another — is now a major focus of Pentagon strategy. "Trying to fight and trying to feed at the same time is something new for us," says an Air Force general. "We're not sure precisely how it's going to work out."

The military take interference very seriously - it's a life and death issue. Deconfliction means organizing operations in a way that minimizes the potential risk of interference and internal conflict, so that separate units or activities can be operated independently and asynchronously.

But deconfliction is often a costly trade-off. Resources are duplicated, and potentially conflicting operations are deliberately inhibited.

As communications become more sophisticated and reliable, it becomes possible to reintroduce some degree of synchronization, to allow units and activities to be orchestrated in more powerful ways. This is the motivation for network-centric warfare, which brings increased power to the edge.

Although the word isn't often used in commercial and administrative organizations, a similar form of deconfliction can be inferred from the way hierarchical organizations are managed, and in traditional accounting structure of budgets and cost centres. This is known to be inflexible and inefficient. Whenever we hear the terms "joined-up management" or "joined-up government", this is a clue that excessive deconfliction has occurred.

Interoperability

Deconfliction leads us towards a negative notion of pseudo-interoperability: X and Y are pseudo-interoperable if they can operate side-by-side without mutual interference.

But there is also a positive notion of real interoperability: X and Y are interoperable if there is some active coordination between them. This forces us to go beyond deconfliction, back towards synchronization.

General Shoomaker: "We've gone from deconfliction of joint capability to interoperability to actually interdependence where we've become more dependent upon each other's capabilities to give us what we need." (CSA Interview, Oct 2004).

Philip Boxer writes: "The traditional way of managing interoperability is through establishing forms of vertical transparency consistent with the way in which the constituent activities have been deconflicted. The new forms of edge role require new forms of horizontal transparency that are consistent with the horizontal forms of linkage needed across enterprise silos to support them. Horizontal transparency enables different forms of accountability to be used that take power to the edge, but which in turn require asymmetric forms of governance." (Double Challenge, March 2006)

Relevance to Service-Oriented Architecture (SOA)

It is sometimes supposed that the SOA agenda is all about decoupling. Requirements models are used to drive decomposition - the identification of services that will not interfere with each other. These services are then designed for maximum reuse, producing low-level economies of scale.

Clearly there are some systems that are excessively rigid, and will benefit from a bit of loosening up.

But this is only one side of the story. While some systems are excessively rigid, there are many others that are hopelessly fragmented. The full potential of SOA comes from decomposition and recomposition.

Further Reading

For more on Service-Oriented Architecture, please subscribe to this blog.

Other Sources

• Statement to the US House Armed Services Committee by Lieut General Robert Wagner, Feb 2004
• Discussion of German translation (update: this URL no longer available)
• Humorous definition of deconfliction from NBC-Links

Interoperability by Design

In his latest Executive Email (Feb 3rd, 2005), Bill Gates discovers a new mantra: Interoperability by Design. Now where have I heard that phrase before?

Here is Admiral Edmund P. Giambastiani Jr, Commander of the US Joint Forces Command, talking to the US Congress in March 2003 (html, pdf). He talks a great deal about collaborative partnerships, coalition partners and "jointness". Here is the key paragraph:

Coherent jointness is the third characteristic of future joint operations, which facilitates coordinated, synergistic employment of the full range of joint capabilities to achieve the desired affects. The interoperability of joint and Service capabilities further enables, and amplifies this common joint ethos. To achieve this synergy of doctrinal, organizational, and human factors, future capabilities must be “born joint.” Interoperability by design in the first instance will permit true integration. It will solve, by moving beyond, the current challenge of de-conflicting service systems that do not talk to each other. Born joint capabilities will require a greater depth of understanding of joint capabilities, an agreed Joint Operating Concept and a shared joint warfighting culture. It enables the execution of seamlessly joint actions at levels appropriate to the mission.

According to Gates, interoperability comes from XML. (The official Microsoft line is that interoperability is all about different software products working together.)

According to Giambastiani, interoperability comes from jointness. (This is clearly system interoperability rather than just software interoperability.) I see this as establishing a significant mandate for collaborative composition.

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