Digital identity is not a two-horse race

Smaller players could gain ground in digital identity while the market waits to see more substance emerge from Microsoft's TrustBridge initiative and the Sun-sponsored Liberty Alliance. A broad range of contenders that could make headway include Novell, Critical Path and AOL, as I've outlined in my column this week on ASPnews. Others I could have mentioned include Computer Associates, Verisign and RSA.

Digital identity is strategically important because it is literally the key to the web services environment. That's why Eric Norlin was right to say Trustbridge is much more than just a tactical response to the Liberty Alliance. Even though its lack of substance is easily mocked (Eric Knorr did so to perfection in this ZDNet column), the announcement actually shows that Microsoft takes digital identity very seriously indeed, as Philip Becker notes in this analysis on the Digital ID World website.

I first drew attention to the importance of digital identity for web services in a report published in January 2000. The relevant section was subsequently published online. It's worth repeating here the timeline that I described then, because re-reading it now I can see that, although I would tidy up some details here and there, it pretty much sums up how I see loosely coupled, on-demand web services evolving:

"This revolution will not happen overnight. It depends on the creation and agreement of standardised definitions for business processes that allow each to be fulfilled by discrete software code components. Here is a likely sequence of events.

• Internet-based applications begin to fragment into software-based component services delivered by multiple third-party providers


• Directory services providers introduce Internet-based 'digital identity' services where users, businesses and applications register their individual profiles


• The emerging dominance of a handful of XML schema such as Microsoft BizTalk provides a framework for universally accepted definitions of business objects and processes


• A new breed of Internet-based packaged software service providers offers the ability to rent ultra-componentised software processes on demand


• A future generation of application service providers allows users to design and build their own applications online in real time from prepackaged online software components

This fragmentation of the application layer into its constituent elements will finally set business free from today's ties to individual application vendors and providers. They will be able to own the business logic that defines their application needs without having to own the underlying software. The applications will then be portable, at will and on demand, from one provider or platform to another."

posted by Phil Wainewright 3:02 PM (GMT) | comments | link

Loose coupling, good or bad?

A welcome debate has been launched by Jon Udell's article last week about loose coupling. Patrick Logan points out that nobody really seems to agree what the term actually means. That's why the debate is welcome, of course — this is too important a notion to leave hanging up in the air.

His weblog posting on the topic — which, as I write this, is labelled 'unfinished', so there's probably more to come — starts by noting that the intention when incorporating loose coupling is to be able to accommodate changes later on with minimum cost and disruption. He then runs through some different examples of how loose coupling can be achieved, though without coming to any major conclusions beyond noting asynchronous communications as a hallmark of loosely coupled systems.

So far so good, particularly as Jon, Patrick and many others who read and respond to their weblogs know far more about programming and development than I do, so I look forward to learning some valuable insights as this debate progresses. Jon begins to move it forward in his initial response to Patrick's posting, bringing the debate round to the role played by "web service orchestration, which is one of the prime motivations for the loosely-coupled design pattern." He notes the possibility that orchestration will "be expressed outside programming languages (eg in XLANG, WSFL, or a successor)" — which I would certainly rate as a possibility.

Returning for a moment though to Patrick Logan's contribution, I'd like to highlight a key paragraph:

Loose coupling is not goodness in and of itself. There is a goal. In an enterprise information system the goal is to provide the information the enterprise wants, when it wants it. That has a cost. Loose coupling can support the cost of change when the enterprise does not have what it wants.

The obvious corollary is that loose coupling carries a cost penalty when the need to accommodate change is absent. Whenever you have a predictable, known set of circumstances, tight coupling wins hands down every time. It's more economical in its use of resources and faster in execution. It should come as no surprise then that in an enterprise computing environment — where every possible step has been taken to remove unpredictability and to pre-empt uncertainty — loose coupling can often look inferior. The more adaptable that enterprise computing environments become, the more they'll need to accommodate loosely coupled techniques. But there will always be some pockets of activity where the processes are indeed so predictable and unchanging that tight integration will remain the superior option.
posted by Phil Wainewright 8:55 AM (GMT) | comments | link

Keep standards simple

Creating ever-more-complex web services standards will hinder adoption, warns Blue Titan Software's chief architect Tony Darugar in an article in July's New Architect magazine: "We could derail our momentum if we make web services yet another convoluted, difficult to understand, and difficult to implement architecture like so many of the object models that have preceded it."

Citing UDDI as a case in point, he cautions against building too many capabilities into the foundation standards of web services. "As we look to enhance Web services with more capabilities and more standards, we must remember the golden rule: Keep the standards simple, and make the implementations powerful ... Web services won't gain ubiquity if they're too complex, and if the changes aren't driven by end users."

Now hold your horses there for a moment, Tony. Do you honestly think companies like Microsoft, IBM and Sun got where they are today by allowing end users to control innovation? Whatever next? I suppose you're going to tell us that end users should be allowed to pick and choose the software functionality they need on demand, instead of having the IT department build their request into a properly planned and resourced project specification.

Anyone who has their irony detector switched on will realize that I had my tongue firmly in my cheek for the whole of the last paragraph. Letting users control not only the standards but also the software automation they need to achieve their business objectives is exactly what I believe web services should deliver. Unfortunately, I also happen to believe that the IT establishment of leading vendors and most IT managers regard that objective as sheer anarchy, acceptable only if it can be tightly locked down within carefully controlled limits.

Therefore the vendors have set up innumerable standards bodies and committees in an attempt to manage web services into existence in a palatable form, one that leaves their market dominance intact and which continues to grow their revenues (all in the best interests of customers, they claim of course). This whole process is one that should be viewed with the irony detector switched to its grimmest setting, for what could be more grimly ironic than watching an industry attempting to hard-wire the very foundation standards of a supposedly flexible new generation of computing?

The industry establishment is approaching the creation of web services standards with exactly the same mindset that it has been building software for the past forty years — it is trying to pre-empt every potential outcome at the design stage. That mindset doesn't work, least of all with web services.

Fortunately it is the market, and not the industry, that decides which standards are ultimately adopted. Out of the anarchy of hundreds of startups jostling to win support for their own proprietary approaches (among them Blue Titan), a consensus will emerge around those that work best for the majority of cases, and those will become the adopted standards. Who knows, some of them even may come out of industry alliances and consortia. But none of these matters can be settled until businesses have started to gain experience from deploying and using web services in real-world deployments.

Those early deployments won't be a breeze — a good discussion of some of the implementation issues can be found in Tip of the Iceberg (PDF, 781k), an article reprint from June's eAI Journal — but this learning process is a necessary phase in the evolution of web services. What's different about web services is that the architecture has built-in tolerance for proprietary implementations of individual components, so early adopters don't have to rip everything out and start again if they find they've made a bad choice for some component of their infrastructure. Instead, they can swap out just that component. Keeping the foundation standards simple during that early phase will maximise the scope for innovation while preserving that all-important interoperability.
posted by Phil Wainewright 3:12 AM (GMT) | comments | link

Hard-wired applications and the EAI scam

Hearing the founders of Cape Clear and Bowstreet on successive evenings is bound to give plenty of food for thought, since both companies are recognized as pioneering standard-bearers in the field of web services. Last Wednesday, I was privileged to hear Cape Clear co-founder and SVP of strategy David Clarke, courtesy of Ecademy. Then on Thursday, I had the equal privilege of hearing Bowstreet founder and chairman Frank Moss, courtesy of European Technology Forum.

What struck me was that both of them were at their most emphatic when describing the effect of web services on today's applications. Neither of them are in any doubt that web services will bring in a completely different approach to application development, one that will very rapidly obsolete today's generation of enterprise suites, along with the EAI tools that purport to link them together.

"We're at the end of the 40-year tyranny of hard-wired applications," Frank Moss told his audience. What he sees instead is the emergence of a new form of application made up of many different components. Business managers will easily be able to reconfigure these composite applications on demand to adapt to changing business needs.

"In five years' time, I believe customers are going to buy application frameworks composed of service components," he said. "There'll be a new breed of vendor that supplies these application frameworks," and of course Bowstreet plans to be one of the leaders of that new breed.

Cape Clear's vision as set out by David Clarke was remarkably similar. He spoke about creating a new breed of software that makes it as easy for non-developers to manipulate application functionality as the early business intelligence tools made it to manipulate data. It shouldn't be necessary to specify a requirement and then wait in line for scarce (and often unresponsive and inflexible) developer resources. "There are more people out there who want to use software opportunistically than want to use it systematically," he said. I like that concept — the notion of software automation on demand, rather than having to wait for it made-to-measure.

Unfortunately, developers don't think about designing applications that way, so one of the big challenges is to change attitudes. That's the problem with using web services in the context of traditional enterprise application integration (EAI) solutions, Moss explained: "What they end up doing is pouring the hard cement of hard-wired applications over these web services." There's no attempt to break the applications down into their constituent functions for easy reassembly later on.

Clarke was more radical in his comments, portraying EAI as little more than a ploy to drive up professional services revenues, one that takes advantage of customers being locked into a hard-wired applications mindset. "EAI is a pyramid scam perpetrated by the software vendors," he said. "Anything given to EAI vendors is a tax on stupidity."
posted by Phil Wainewright 11:54 AM (GMT) | comments | link