Let users own process integration

Instead of trying to erase users out of the process automation stack, software developers should explicitly write them into the system. It's long been recognized that "manual integration" — also known as "swivel-chair" integration, when users cut-and-paste information from one application to another — is probably the most prevalent form of enterprise application integration (EAI) in use today. A succession of workflow, EAI and now web services vendors have insisted that they have the solution to this problem, and it usually consists of buying their product along with lots of consulting time so that the missing processes can be identified, programmed into the system, and finally automated.

But you know what happens in reality, don't you? As soon as the newly automated processes are rolled out, users find new processes that haven't been automated, and they start improvising a whole new wave of manual integrations. The only way to interrupt this endless loop is to stop trying to automate the operational processes in advance, and instead start giving users tools that help them improvise new processes more efficiently.

What started me off on this train of thought was Jon Udell's thoughts on integration after speaking to Cape Clear's Annrai O'Toole, who identifies three layers in the integration stack. Having SOAP deployed as standard in Windows fixes one layer, he believes. XML data representation fixes another. The third is business process integration, which he believes will be much harder to fix: "He thinks we'll still need to do a lot of scripting to glue things together." I think the key to the fix is to recognize that the we in that sentence doesn't mean developers or software vendors or even IT staff. The we is all of us — as users — and the role of developers and vendors is to give us tools that generate the script to do the things we need to do, on demand.
posted by Phil Wainewright 1:58 AM (GMT) | comments | link

Frankenstein feeds

There's a danger that the sudden flourishing of creativity in syndication feeds unleashed by RSS 2.0 may, like genetically modified crops, lead to dire unintended consequences. To help reduce the risk of an epidemic of "Frankenstein feeds" overwhelming the delicate ecosystem of online syndication, I have begun to document what seems to me to be mainstream best practice in the use of RSS 2.0 feeds. I am doing this on my other blog, AppSwitching Diary, which is where I record observations and tutorials about lessons learnt while building Loosely Coupled (which is why it's labelled simply 'howto' on the navbar above).

This is basically taking up Dave Winer's suggestion of a 'Busy Developer's Guide to RSS 2.0', but written by a webmaster rather than a developer. I've started today with 2.0 Lite — click through to read more.

NOTE: That would be way cool says Sam Ruby, who also warns it's a big task. Well, I may not do it to everyone's satisfaction but at least I can get the ball rolling. Thanks Sam for the encouragement. Actually, this posting wasn't meant to appear until Friday morning but I didn't leave it marked as draft, and it got published overnight when Blogger was testing a fix for me. So that's why there was nothing to read over on the Diary when Sam clicked through. I'll publish the first instalment this morning.
posted by Phil Wainewright 1:16 PM (GMT) | comments | link

Standards politics and Sun

Playing standards bodies is a political game, and some vendors do it better than others. Oracle displayed consummate skill at the W3C last week with its proposal to seek a single standard for web services choreography, as described in my ASPnews column this week. Sun on the other hand is uniquely ill-equipped to work the standards process, as it demonstrated once again yesterday with its own belated call for convergence on choreography.

While I have every sympathy for Sun's feelings about its deliberate exclusion from IBM and Microsoft's Web Services Interoperability club (WS-I), I cannot help but feel utterly scornful of its abject failure to understand the politics of standards bodies. Did no-one think to tell Mark Bauhaus (who as VP of Java web services should have known anyway) that for Sun to call for some kind of action on choreography standards was going to sound a bit vague and out-of-touch, coming a week after Oracle had actually got the W3C to agree to take action on the very same issue? Honestly, sometimes you get the impression these people live in a world all of their own.

One of the several sessions I would have loved to attend at InfoWorld's Next-Generation Web Services conference this week in California is Amy Wohl's presentation tomorrow afternoon on The Hidden Agendas Behind Web Services Standards. Unfortunately, I'm still deskbound here in London while work continues on the commercial elements of LooselyCoupled.com (of which more later). But if I were there, I would be tempted to take Jonathan Schwartz, Sun's EVP of software, to one side after his keynote this evening, and recommend him to encourage as many of his colleagues as possible to take the short drive down Highway 101 to hear what she has to say. It is a subject on which I fear they are all sorely in need of some sound advice and guidance.
posted by Phil Wainewright 4:43 AM (GMT) | comments | link

Simonyi continues his quest

The man who pioneered the development of applications at Microsoft has left the company to found a startup devoted to a new method of automating the creation of software code. Charles Simonyi, who joined Microsoft in 1981 to lead development of the company's desktop application portfolio, left last month with the company's blessing to set up the new venture, Intentional Software. The news was made public yesterday.

Intentional is so named because its products will create source code using graphic images, charts and text that represent the design intent of the developer. The company claims this will make it easier to develop, maintain and change software, since the source code will directly express the outcomes that it aims to achieve. In the words of an article in yesterday's Seattle Post-Intelligencer, this will be "software that explains itself, revealing its intention to whoever looks at the source code, or blueprint, rather than appearing as cryptic symbols that anyone other than the original coder might have trouble understanding."

Simonyi, described in the article as "scarily bright" by a former colleague, claims Intentional's tools could make software virtually bug-free, by removing the scope for human error in the same way that the move from manual switchboard operators to automated switches improved the accuracy of placing a phone call. "Now that the caller, not the operator, does the work of connecting, mistakes may occur through misdialing, but 'those are mistakes you caused, not errors in implementation'," he told the Seattle newspaper.

The approach, which is also known as aspect-based programming, has been the focus of much of Simonyi's work at Microsoft Research in the past ten years. The desire to find a way to create software more efficiently also brings to mind his 1970s stint at the Xerox PARC research center, where his doctoral thesis, Meta-Programming: A Software Production Method, described a way of organizing programmers into what Bill Gates later described as a "software factory", according to the account in Robert X Cringely's book, Accidental Empires.

The desire to remove imperfections and disconnects in the process of translating software design into execution is a common quest today, not least among proponents of business process management systems, as I wrote last week. But whereas business process advocates seek to put direct control in the hands of business managers and analysts, Intentional's tools will be aimed at a small echelon of developers. Indeed, one reason advanced for his departure from Microsoft is that the company believes aspect programming tools will appeal only to a small, specialist market.

In an arrangement reminiscent of the development of Notes, which Lotus originally span off into an independent company led by Ray Ozzie, Microsoft has retained first rights to license software developed by the new venture, but it does not have a stake in the company. The estimated $5m in startup capital it requires will be funded from the estimated $1 billion personal fortune that Simonyi has built up during his long tenure at Microsoft.
posted by Phil Wainewright 7:02 AM (GMT) | comments | link

Sun goes shopping for startups

Sun is on the lookout for startups that will add to its product portfolio, reports the451 in an analysis published by SearchWebServices.com. Several web services startups will come near the top of its list because they are led by Sun alumni, says the451's Rachel Chalmers, quoting Systinet and AmberPoint as two prime candidates.

Describing Sun as "a compulsive shopper for technically proficient startups," the report is based on statements by Sun executives indicating their interest in making such acquisitions. But the identification of web services as a target sector, let alone the identities of individual candidates, is pure speculation on the part of the author.

She makes a persuasive case, nevertheless, and the acquisition of a high-profile startup would certainly help bolster Sun's web services credentials, just as BEA and Novell each strengthened their positions by acquiring, respectively, Crossgain and SilverStream. It will help other startups too, since with venture capital in scarce supply and no prospect of the IPO market making a comeback, a steady flow of trade sales to larger vendors is the best way of maintaining investor interest in the sector.
posted by Phil Wainewright 5:19 AM (GMT) | comments | link

Syndication matters

A website is not a destination, it's a starting point — the source from which its owner distributes information, content and services out to the network. In a service-oriented network, a website doesn't need to have any 'visitors' to be influential. Think Microsoft Passport, which validates millions of user IDs daily, or Atomz Search, which serves up millions of search results on behalf of its customers' sites.

That's why syndication matters, along with the seemingly arcane debate about RSS 2.0. Today, the main use of RSS is to serve up content and information from online news sites and weblogs, but it also has the potential to serve as a low-risk testbed for syndication processes and business models that could later on be applied to the delivery of more sophisticated web services. All it needs is wider adoption, and then we'll start to see new uses, for example in the business world as a simple means of distributing corporate information such as product updates, company news and up-to-date contact details. So this is about much more than syndicating weblog postings.

But creativity in the exploitation of RSS has been stymied by a standards impasse. In a posting this weekend to a discussion on Blogroots, Dave Winer accurately summed up the current status of the two opposing sides of the debate. Meanwhile, I've been having a small debate of my own with Dave in the comments thread to my last posting on this topic here on Loosely Coupled. Here's an excerpt from Dave's last remarks, responding to my point that leaving little-used elements in the spec increases the learning curve for new adopters:

"... there's no reason we can't have a Busy Developer's Guide to RSS 2.0, that (like the one we did for SOAP 1.1) focuses on what you need to know to get started with a RSS 2.0 implementation. And I don't want to be the only one writing such a document. I think not breaking trust with developers is a prime directive, that any time you try to break a format or protocol it backfires, developers freeze, forward motion stops. I've seen it happen many many times."

Dave speaks with the weight of many years' experience as a developer, whereas I have just a few hours pottering about in PHP to my name, so I respect his evident reluctance to break trust. And I think his suggestion of a quickstart guide answers my objection. Even though the hoped-for unanimity from all sides in this debate doesn't seem to be likely, from my readings of what people have been saying in weblogs over the past ten days or so, I detect enough of a consensus to be able to move forward.

What seems likely to emerge is that we're going to have three-and-a-half varieties of RSS, but with the saving grace that three of them will be part of RSS 2.0, which should provide enough common ground to prevent anyone being left high-and-dry:

• 2.0 Lite will be a bare-bones implementation that is fully backwards compatible with RSS 0.9x readers but which, more importantly, refrains from using any of the optional attributes that have mounted up as the specification progressed through its 0.92 and 0.94 versions.
  
• 2.0 Rich will be a full-function implementation that makes full use of XML namespaces, including the use of namespace-based alternatives in place of the optional attributes from 0.92 and 0.94. Mark Pilgrim recently created examples of what both Rich and Lite might look like (he refers to them as "basic" and "complex").


• 2.0 Classic will be the fully backwards compatible variety, which implements whatever elements and attributes of RSS 2.0 the developer pleases.


• 1.0 is the "and-a-half" in addition to the above three. Its inclusion of what co-author Rael Dornfest recently conceded was the "RDF tax" of RDF compliance may have made it technically superior, but 0.9x loyalists perceived it as taxation without representation, and it has not proved popular. Nevertheless, bypassing 1.0 in favour of 2.0 bears the risk that the semantic web people were right all along and that one day the purported merits of 1.0 will come back to haunt us.

In the meantime, 'Basic', 'Rich' and 'Classic' will all be equally respectable choices, and they will be fully interoperable, sharing the same core elements and able to simply ignore any elements they don't understand in any feed they encounter. The most dangerous suggestion here is 'Rich'. It's basically an incitement to create an alternative specification within the specification, and its success depends on having some best practice examples available as early as possible so that, out of all the possible variations, some unanimity of adoption emerges. That's why I warmed to Dave's suggestion of a 'Busy Developer's Guide', because it seemed to me to be a way of documenting all these variations and providing a touchstone to prevent things getting out of hand. Still, if it doesn't work out, there will always be 'Classic' to fall back on. Which, after all, is another good reason for preserving it, baggage and all.

UPDATE: Notable comments so far:

• Dave Winer: "I agree with this ..."


• Sam Ruby: "Should titles be required in 2.0 lite?"


• Ben Hammersley: "version 2.0 of RSS is *not*done*yet* ..."

posted by Phil Wainewright 7:06 AM (GMT) | comments | link