Weekly notes: Software futures

WS-ReliableMessaging arrives, ESB needs mediation, service assembly tools, semantic context, capturing process. Future trends in software seems to be the theme running through this week's notes, although there's also word of a minor spat between two Irish ESB vendors and news of yet another SAP implementation gone wrong.

# WS-ReliableMessaging arrives. Two more products announced this week include support for WSRM, heralding the arrival of this fledling specification into the market as a production technology. The newcomers were Cape Clear's upgraded web services integration platform (or ESB, as the company likes to call it) and BEA's 9.0 release of its WebLogic Server, which is codenamed Diablo. They join Blue Titan's Network Director RM, announced last month. Along with security, reliability was one of the missing attributes most often cited as blocking enterprise adoption of web services technology. Once WSRM finally starts shipping in these products when they become available early next year, it will get its chance to prove itself in production deployments, and that will be one more objection dealt with in the web services sales cycle.

# ESB: no dead end. We published a strong defence of ESB this week penned by ESB vendor PolarLake's CEO, Ronan Bradley: Saving ESB from a dead end. Ronan maintains that web services have failed to gain ground in large enterprise projects because the core technology doesn't provide for integration with existing infrastructure. That's where ESB comes in, he says, but he adds that vital mediation capabilities to transform messages between systems are often missing from rival vendors' products. Loosely Coupled's editorial position is normally a lot more favorable to web services than Ronan's article, but I can rephrase his argument in a way that makes it absolutely aligned with our views: neither web services nor ESB are any good to anyone unless complemented by mediation capabilities. I should also add that PolarLake was the first ESB vendor to add BPEL support to its product, which it did back in August this year — contrary to Cape Clear's claim that its new product will be the "world's first Enterprise Service Bus with native BPEL technology." Since both companies are based in Dublin and their CEOs both previously worked at Iona Technologies, this is a curious oversight on Cape Clear's part.

# Service assembly tools are an emerging sector of products that, once an enterprise has created a service-oriented infrastructure, make it possible for non-developers to build new applications by combining existing services. New vendors in this emerging sector include Skyway Software, founded by former principals of B2B trading platform Tradex Technologies, whose product has recently been adopted by SOA pioneer British American Tobacco (BAT) as a successor to Lotus Domino for rapid business application assembly.

# The future of software was the theme of a special report by Information Week, and one article that caught my eye was Apps To Die For. It predicts a rosy future for organizations that adopt service-oriented architectures who, it says, "may have a jump on building the next potentially transformative application component. Some will build components that solve universal business problems, but many more will simply and elegantly address processes specific to particular industries." Many of those organizations will go on to offer those components to others as on-demand services, the article predicts, but they'll need to get the semantic context right (the mediation, as Ronan Bradley would call it): "if a Web-services component has specific instructions on the descriptive parameters it must conform to when grabbing data, it increases the likelihood of delivering useful information."

# Capturing process is one of the biggest challenges when deploying software for business automation. If these future visions of service-oriented application assembly are to turn out well, it's vital that services are accurately and unambigiously described, and that they are assembled into applications by people that intimately understand the business processes they are supposed to automate. Last week, CRM Daily reported on a SAP rollout at City of Tacoma that went horribly wrong because the municipality didn't realize the difficulties it would have when it replaced its existing legacy processes with SAP's automated ones: "'The problems have tended to be mostly the result of implementing new processes and formats that SAP supports,' said Mark Crisson, CEO of Tacoma Public Utilities. For instance, some of the bills the CRM application generated were difficult to understand compared with their prior format and led to a flood of service requests." This week, research from Delphi Group found that this type of experience is far from unusual. "[The survey] suggests that a significant part of the problem in tackling major IT projects lies not in the software itself, but in the business processes surrounding the deployment," reported InfoWorld. "Close to 90 percent [of respondents] said incomplete definition or capture of business requirements is at least a moderate problem in their organization." Delphi suggests that poor definition of business processes could be a "root cause" of widespread software project failures. Well, doh! If you don't understand what you're automating, then the chances of the automation being successful are entirely random — and the probability of failure is calamitously high. And yet enterprises implementing major software packages today routinely replace processes they've never fully investigated with automation whose process impact they've never quantified. One day, we will look back and be surprised we ever put up with such a state of affairs.

posted by Phil Wainewright 11:52 PM (GMT) | comments | link