to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


Loosely Coupled weblog

Friday, May 6, 2005

Dissolving boundaries

Anyone who wants to pigeonhole SOA is in for a disappointment. The move to service-oriented architectures in computing is part of a trend that will permeate widely, and the one thing you can guarantee is that it won't fit neatly into your existing view of the world — it is going to dissolve existing boundaries and create a new landscape.

Wednesday's [May 4th] ZapForum debate about ESB versus SOA fabric (which I previewed last week in my WS-Fabric posting) seemed to me to be symptomatic of this tension. The notion of ESB that Sonic Software's Gordon van Huizen was putting forward seemed to be one of containment, of preserving existing boundaries. At one point, he was talking about application services being external to the ESB. Perhaps I misinterpreted, but this seems to me to be a throwback to an earlier notion of computing, when every application sat neatly in its own stovepipe and the role of middleware was to forge connections between those separate containers. Yet later on, Gordon clearly agreed with Blue Titan's Frank Martinez that much of the logic involved in creating composite applications must reside in the connecting fabric. So although it may be helpful initially to think of applications as separate entities that must be joined to the SOA, the boundaries will soon dissolve as their functionality begins to be absorbed into new, composite processes that straddle multiple application nodes.

To my mind, maintaining an artifical divide between the component applications and the service-oriented infrastructure that joins them together is not going to allow you to realize the greatest benefits of adopting SOA. It's only by breaking down these monolithic applications into more atomic functionality that you can start to achieve meaningful reuse and flexible reassembly. So instead of keeping them separate, you must allow the SOA fabric to cross the boundaries and start to seep inside the applications, beginning the process of breaking them down.

A common refrain in the call was that people are looking for design patterns for ESB and SOA. I don't feel anyone got a satisfactory answer to that. But perhaps that's because there are no constants so early in the evolution of SOA. We are at the beginning of a journey in which we first join the components together and then begin to disassemble them so they can be re-made for the SOA environment. This is a journey of cumulative reinvention, and we are so far away from reaching the final destination that there is little clarity as to what it will look like when we get there.

Phil Becker does a great job of describing how perceptions are gradually being changed as the sophistication of networking increases in his latest newsletter. Annoyingly, Phil doesn't post his newsletters online until he gets around to it (the most recent on the Digital ID World website as I write this is the March 31st one) so I'll have to quote large chunks of it here. (Since Phil is busy preparing for next week's Digital ID World Conference, I doubt he'll get around to posting that newsletter for a while yet).

"Networked computing has three underlying constructs," writes Phil. "Not all of these were obvious at first. They were 'discovered' along the way. Networking began as a challenge to connect computers together at a communications level. The infamous OSI seven layer abstraction of networking is entirely focused on communications. This was the natural starting point ...

"With the general solution of the communications construct began a phase of widespread adoption of networking that led to the internet boom and bust of the late 1990s. Along the way, however, the fact that software and computers came to be easily networkable started to exert another pull - on the architecture of computing, and the way we design and build applications ... This too was inevitable, since as soon as computing could presume the existence of a widely accessible communications network with sufficient bandwidth, applications themselves were naturally drawn to reshape their architecture to fit and leverage that presumption [emphasis added]. This has relentlessly led to more loosely coupled application development, and now service oriented architecture through Web services. Thus loosely coupled, distributed methods of computing form the second construct of networked computing - the architectural construct.

"... just as the maturation of the communications construct of networking in the early 1990s led to the discovery and development of the architectural construct of networked computing, the emerging maturation of that architectural construct is today causing us to discover and begin to develop the third construct integral to the nature of networked computing - identity. Identity is the organizing construct of networked computing. That is why it is so important ...

Note that each of these fundamental networking constructs was discovered only as a result of deploying the previous one [emphasis added]. Each took about a decade to reach pubesence, and each created a market larger than the previous one. The same will be true for identity ...

What I find intriguing about this line of thought is that it begs the question, 'What comes after identity?' I think Phil is right to emphasize the importance of identity (although I prefer to talk about 'profile', since identity as a word is bound up with notions of human individuality; many of the identities of importance in a network belong to abstract and virtual entities, whereas very few of them relate to specific users). But I'm not sure that it's the whole of the next networking construct; I think that ontology/semantics also comes into it. I suspect Phil might well argue that these are aspects of identity, but others would probably retort that assigning identity is impossible unless you've already established shared meaning, and that semantics therefore comes first. What's beyond argument is that both are necessary and neither are well understood at present, which brings me back to my starting point. The move to SOA is forcing us to confront topics like identity and semantics, because the boundaries that previously existed between separate pools of trust and meaning are dissolving. This has far-reaching consequences for the way we organize and consume computing.

It also impacts the way we organize businesses. Most of us have a mind's eye image of businesses as walled citadels, but I recall a discussion with John Seely Brown a while back in which the question was raised, where is the edge of the enterprise? Organizations aren't like buildings, with walls and roofs. They're collections of people, many of whom interact with outsiders: legal interacts with attorneys, HR interacts with employment agencies and payroll providers, finance interacts with the bank. Think about that and you realize that the move to SOA is really a matter of computing catching up with where business already is. What SOA does is to make these edge interactions even easier to set up and conduct at all points within the enterprise, dissolving the boundaries in creative new ways.

The other important trend that interlocks with this is the growth in what others call software-as-a-service (and which I prefer to call software-powered services). Consuming other people's computing becomes much easier and less risky within the context of SOA. But why stop at computing. Why not consume other people's software-powered business services? As James Governor says, "The more i think about what service oriented architecture means the more i realize loosely coupled has to go beyond lip service. Organizations as much as as architectures must be decoupled, so they can be remixed." [Thanks to Koranteng for the link and also for so much else to think about].

So the move to SOA is dissolving and reshaping boundaries not only between islands of computing and application functionality, but also between businesses and islands of business activity. There's a huge transformation under way, and Loosely Coupled will be reporting on and analyzing the practical implications — the best practice lessons and pitfalls — of each of these trends as enterprises begin to deploy and harness their potential.

posted by Phil Wainewright 2:12 PM (GMT) | comments | link

Assembling on-demand services to automate business, commerce, and the sharing of knowledge

read an RSS feed from this weblog



latest stories RSS source

Headline news RSS source


Copyright © 2002-2005, Procullux Media Ltd. All Rights Reserved.