to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 
 Glossary lookup:

 

Loosely Coupled weblog


Friday, April 18, 2003

It's better by bus
Everyone is talking about the integrated business and the real-time enterprise as if these are new things enabled by next-generation technology. But can anyone show me a healthy enterprise that's dis-integrated or which doesn't operate in real time? It's a nonsense. It's not the organizations that have these problems, it's the IT they're using. The dirty secret hiding behind these buzzwords is that IT has never delivered the real-time integration that businesses need to perform their day-to-day operations. The result is that the people who work for those organizations have to run around filling in the cracks and tying up the loose ends, making up for the shortcomings of the technology.

This week was a great week for those of us who long for the day when technology finally catches up with the way businesses operate in the real world. The key to this is the creation of a service-oriented IT architecture that permits integration to take place at the level of business processes rather than down in the application or database infrastructure. With excellent timing, analyst group ZapThink have just published a new report by Ron Schmelzer that sets out how this will work, and how enterprises can get there: Service-Oriented Process: Meeting the Requirements of Business Agility with SOA-based Process. News articles at CNET and at internetnews.com include some quotes from Ron that elaborate on the message.

"By approaching a service oriented architecture from a business process perspective, it will buy you all of the things people are trying to solve with integration products today," Ron told internetnews.com. The implication of that is a lot less spending on expensive EAI tools: "If you've really implemented service oriented architectures correctly, you shouldn't need an integration system."

Of course, ZapThink are SOA groupies. Taking a more restrained view, Gartner has just published an overview of its thinking on SOA, complete with links to the various research it has available on the topic (including several new papers). "A myth has emerged in the industry that SOA and web services are the modern answer for the application integration problem," writes Gartner analyst Yefim Natis. "In reality, SOA is indeed helpful in some cases of integration (real-time composite transactions), but it is less useful in others."

But it's not that Gartner disagrees with the overall direction in which things are moving, so much as what it will take to get them there. SOA approaches need to be complemented by event-driven architecture (EDA), writes Natis, before going on to predict that business process engineering projects will eventually resolve the equilibrium between the two models: "Business process management technology will emerge as the crucial link in extending the momentum of SOA to EDA and, thus, in completing the fundamental architectural pattern of modern, agile enterprise IT: It is service-oriented and event-driven."

BPM of course took a huge step forward this week with the submission of BPEL4WS to OASIS, which I wrote about in my previous posting. I've now learnt that Intalio, which is the main sponsor of rival specification BPML, elected to act as one of the co-submitters of BPEL4WS. Its position on BPML, to quote its official Q&A on the topic, is this: "We believe that the time has come to strive for consolidation." With all the main proponents of BPM now united around the OASIS submission, there should be little doubt that this is going to be the platform for convergence on a single standards stack for process co-ordination.

With so much going on this week, one of the most important announcements was in danger of getting drowned out. There was surprisingly little coverage of Sonic Software's launch of ESB 5.0, the new version of its Java messaging bus server, along with the announcement of an accompanying business integration suite. Only InfoWorld's story did it justice (accompanied by an interview with Sonic vice-president Gordon van Huizen). I have a feeling this will be one of those events in the history of this industry whose significance will only be recognized in retrospect. Let me explain why I believe it's such a landmark.

Sonic changed the name of their product to ESB in order to align it with "Enterprise Service Bus," a term Gartner endorsed in December when it published a paper called Predicts 2003: Enterprise Service Buses Emerge. That paper was republished online in March as part of a Sonic-sponsored document, The Future of Integration. It defines an ESB as "a standards-based integration backbone that combines messaging, web services, transformation and intelligent routing to reliably connect and coordinate the interaction of hundreds of application endpoints spanning a global organization." What this means is that it can act as foundation infrastructure for both SOA and EDA, to borrow the terms Yefim Natis has been using in Gartner's SOA commentary cited above.

The Sonic/Gartner primer continues: "The design center of an ESB is that of a federated integration network, not a hub-and-spoke server-centric model ... the federated network ensures massive linear scalability, just like the Internet ... Introducing a new application as a service into the bus promotes a network effect — the new application can now interact with any service on the bus, and in turn, other services can interact with the new application."

Inspired by attributes like these, IDC has now come out in support of the ESB concept. But whereas Gartner merely states it will be "widely used" and "have a major impact on several segments of the software market," IDC is much more gung-ho: "The ESB is an open standards-based technology concept that will revolutionize IT and enable flexible and scalable distributed computing for generations to come."

In other words, this is a hot technology. But there's more. The price point is hotter still, and at several levels:

  • Development costs are low. According to Sonic/Gartner: "the technologies used within an ESB are entirely standards-based. The core technical prerequisites include an understanding of XML technologies like XSLT and XPATH, and where programming is required, an understanding of Java and JavaScript. The benefit of this is that ESB integration projects will require substantially less outsourcing to consultants and allow organizations to leverage existing IT staff." (Perhaps that's what Annrai meant).

  • You can start small (just like the advice in Monday's article, Tactics, not strategy, drive SOA adoption). Sonic/Gartner again: "Even if an enterprise starts small with one integration project ... the infrastructure can readily extend as broadly as necessary."

  • Sonic announced some very important companion products this week, based on technology the company acquired when it bought XML database vendor eXcelon last October (see Progress buys eXcelon for Sonic boom). There's an XML server for storage and transformation of documents being exchanged on the bus, there's an orchestration server for co-ordinating and analysing longer-running processes, and there's a process modeling tool. These add up to a powerful set of process integration capabilities on top of the bus itself.

  • The price per CPU for each of these components, including the bus server itself, is either $10k or $12.5k, which is as much as an order of magnitude less than equivalent products from conventional integration and orchestration vendors. Sonic is running with the 'disruptive technology' message in a very aggressive way, and has some case studies that actually show customers putting in Sonic solutions for a tenth of the cost of conventional equivalents.


When I met with VP of marketing Tim Dempsey on Monday, he was quoting figures that said just 15% of applications have any integration at all. Sonic's calculation is that price and skills availability are the main barriers preventing wider adoption, and so the company has decided to price at a level that will prove attractive to the 85% of the market whose needs are not being catered for at the moment. "Our intention is to disrupt the integration [software] category," he told me. "This is going to provide a fundamentally different economic foundation for integration."
posted by Phil Wainewright 12:58 PM (GMT) | comments | link

Wednesday, April 16, 2003

Up to speed with BPEL4WS 1.1
Not only is BPEL4WS about to be handed to OASIS, thus putting it well on the way to becoming the royalty-free standard for business process orchestration and choreography, but it is also being submitted as version 1.1, which tidies up some important loose ends in 1.0. So this looks to be a landmark week for web services-based business process co-ordination.

The submission will apparently be backed by 20 or so companies, including SAP and Siebel, which will give it more than enough momentum to confirm the irrelevance of the W3C's WS-Choreograpy working group, recently orchestrated (if that's the right word) by Oracle. I don't hold with CNET's headline on their coverage, Web services standards facing a split?. It's more a case of web services standards facing convergence.

I understand from orchestration server vendor Collaxa's Edwin Khodabakchian that BPEL4WS 1.1 improves the separation of elements involved in orchestration and choreography, which should help answer some of the issues that might previously have justified a separate choreography standard like W3C's WSCI. Meanwhile, Ismael Ghalimi of Intalio, who is co-chair of BPMI.org, the other standards group in this field, told me last week that the underlying model of BPEL 1.1 brings it closer to his group's BPML. And finally, of course, OASIS is the guardian of ebXML and the associated BPSS and BTP specifications, which are the other key players that need to be brought in line so that everyone is orchestrating from the same songsheet, if that's not too much of a lame metaphor.

All of this bodes well for a calm resolution of standards in a key layer of the SOA stack, which sits above security and messaging and, as Ismael Ghalimi notes in my article yesterday, Tactics, not strategy, drive SOA adoption, is at a level that delivers benefits that are visible to business people. In fact, he said something else that I didn't quote there but now seems very relevant here: "BPM is very much a killer app for web services or SOA."

Collaxa has put together an excellent 'Fast Facts' document on BPEL4WS 1.1, and I was about to link to it here, but I have a feeling it's embargoed until the announcement is made official (UPDATE Apr 17th: Last night, IBM published the BPEL4WS 1.1 spec, and Collaxa has now published its fast facts on BPEL4WS 1.1 and its submission to OASIS).

Another article that's timely for those who want to dig more into the technical background is an XML.com article XML Transactions for Web Services. And of course there are lots of previous references to resources on this topic scattered around the Loosely Coupled site. You can find them by using the search or glossary functions. Obviously we'll be updating the relevant glossary entries to reflect this latest news once it becomes official.
posted by Phil Wainewright 1:58 AM (GMT) | comments | link

Tuesday, April 15, 2003

What is the tipping point for SOA?
Lawrence Wilkes of CBDI sent me an eloquent email last week about the tipping point for adoption of web services and SOA. Very often, this kind of material gets collected in the course of researching an article and then discarded, but I felt it was worth quoting in full, so with his permission we've published it today as SOA and web services. As it happens, Loosely Coupled will soon be launching a series of contributed opinion articles, so it has ended up becoming the first of that series.

The article I had been working on was prompted by hearing a lot of grand talk about SOA strategies, at the same time as being told that the majority of web services projects are small-scale, opportunistic deployments. It didn't seem to add up, and it turns out my hunch was right. The anecdotal evidence from speaking to a cross-section of web services vendors with significant customer bases is that most customers have no SOA strategy at all. A handful (mostly CBDI subscribers) have one; a larger minority aspire to one; and the majority will wait until events thrust one upon them. The article is Tactics, not strategy, drive SOA adoption.

So the tipping point in most organizations will come when piecemeal web services adoption reaches sufficient mass to coalesce into a distributed service oriented infrastructure. That's when the need for an SOA becomes self-evident (note the distinction between ad hoc infrastructure and a planned, manageable architecture). But of course, as anyone who has read about network theory will know, such transitions have a habit of being both unexpected and yet overwhelming in their impact. If you're unprepared when it happens, the only appropriate reaction is, "Panic!"

The good news is that people are already thinking about SOA, and have plenty of guides from the likes of CBDI, Zapthink and others to help them get there (we publish a directory of analyst resources that points to a wide selection). The thorny question of how to persuade the business to invest in SOA infrastructure was on the mind of John McDowall of Grand Central Communications, writing in his personal blog this weekend: "... the true value of web services and the resulting common infrastructure that is being built ... is about universal communication between business processes .... it is about enabling communication and shared context."

Somehow, though, I don't think it's going to be that difficult to sell it to business people once they see the results starting to come through. Service infrastructure seems to be much cheaper to implement than previous generations of IT, and the projects that are going ahead first are the ones that are able to deliver quick returns. Once adoption begins, it has a habit of gaining a momentum of its own, and by the time the tipping point for SOA arrives, it's already too late to go back.
posted by Phil Wainewright 6:27 AM (GMT) | comments | link

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

read an RSS feed from this weblog

current


archives

latest stories RSS source


Headline news RSS source


 
 


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