Self-service SOA, the Salesforce way

Yesterday's announcement of Salesforce SOA gives's customers a convenient way of bringing SOA into its SaaS garden. Many customers will welcome that convenience, but others may feel restricted.

The convergence of SOA and SaaS continues apace. Yesterday announced Salesforce SOA, an add-on to its Apex development environment that allows users to access external web services — anything from an RSS feed to a full-on SOAP stream from an enterprise application.

I have to say this is neither revolutionary nor surprising, but it is significant. If hadn't done this, I would have been surprised. All development environments these days include the ability to access web services, and Apex is now no different in that respect. Of course Apex is a little unusual in being a hosted development environment, but it's not unique in that respect either — Bungee Labs' Connect environment springs to mind as another example. So the banner at the top of's website today claiming the "first software as service SOA solution" is the usual brash overstatement we've come to expect from the vendor.

But let's get a little excited about this announcement, nevertheless. It is a first in the sense that's market presence will put the notion of hosted SOA front-of-mind for enterprise buyers. That may start them calculating the advantages of using a hosted SOA solution, as Dave Linthicum emphasized yesterday:

"Now, SOA architects, developers, process designers have a less expensive way to build, deploy, orchestrate, and manage services using a holistic, single source stack."

Another important factor is the environment, which is designed to serve business users as well as developers. Bungee Labs' Alex Barnett, watching Marc Benioff unveil Salesforce SOA yesterday, was impressed by the way it's been implemented:

"The wiring experience is not a dev UX environment, but an html form based with some Ajax interaction — more of a business user interface to wire stuff up. Nice."

So far, so good. But let's also remember that vendors don't create development environments solely for the convenience of their customers. They also like the way that they lock customers into their platform. Salesforce has now provided its customers a convenient way of bringing SOA into its SaaS garden. Many customers will welcome that convenience, but others may feel restricted.

As I wrote last week, there are ways of doing SaaS integration without the lock-in. Bringing SOA into is one way of doing SaaS integration, but if customers want to avoid vendor lock-in, they may want to investigate using a neutral intermediary, such as a services bus, rather than the point-to-point integration that's inherent in the Salesforce SOA approach. It will be interesting whether, as the space evolves, we'll see the emergence of hosted intermediary services to fill that need, or whether the services bus remains an on-premises phenomenon.