Mashing up the Enterprise through SOA and BPM

I am trying to find examples of implementations of Web 2.0 concepts/technologies in the enterprise in advance of my upcoming panel: “Web 2.0 and the Enterprise”. I was therefore very interested in David Berlind’s recent post on “Rethinking BPM in a mashup-based SOA world” – a worthy read if you are tracking the topic.

There are a large number of issues involving enterprise mashups, David pointing out to a couple of them:

 To wit, attendees from the banking and government sectors have questions about the management of user IDs across domains (when a mashup involves multiple APIs each of which relies on its own identity management technology) as well as the reliability of public components.  For example, if an enterprise dispatch application along the lines of what Kemsley describes above relies on Google or Yahoo for its mapping component, enterprise architects want to know what Google and Yahoo are doing to ensure the uptime of the relevant APIs (a particularly relevant question given the recent outages at the Software-as-a-Service-based Salesforce.com).

[…]

Best practices on the API evolution front are also a concern; not just to enterprise architects, but also to mashup developers looking to turn their innovation into a business.  As API providers improve their APIs, what measures are they taking to make sure that those improvements don't break the existing applications and mashups that rely on them (can you imagine an enterprise application grinding to a halt due to changes in one of the APIs it relies on?).

Comments

[Dennis Howlett]

Jeff - this is a much more complex issue than people imagine. The issue of identity or reputation management is critical. I do know of one company that's trying to solve this but only one. I sign on to multiple services across multiple domains. How the heck am I supposed to remember all of them? so what do I do - same username/same password or pretty much the same - wherever I go. What I want is a service based on open standards where my initial password forms the basis for generating a strong, encrypted key that I don't have to know about and which is secured in a virtual vault. Some will say this is inherently weak but I disagree. Go find 'em buddy.

When it comes to the banks - do you honestly think you'll ever get consensus on the issues raised? They can't even deliver on STP1. Basel II is in the wings and I'll bet a pound to a pinch of snuff that few in Europe have heard about MIFID - which absolutely plays directly to SOA and BPM. Start there.

[sandy kemsley]

I believe that the "outage" argument is spurious: I often work as a consultant embedded within a large organization, and more outages happen inside those organizations -- and are never reported outside -- than you will ever see from salesforce.com.

The API interface/behaviour changes are more of an issue, but that's the case with any third-party service or software on which an organization builds custom code, or even services built by another part of the organization. I have frequently (and recently) seen situations where an upgrade to a software package "broke" the custom code that calls it, either because the calling app was using an undocumented or unsupported API, or because the vendor changed the interface and didn't do proper regression testing. Mashup API authors will live or die in the global SOA ecosystem by their ability to provide good functionality, appropriate uptime, and consistent interfaces.

The moral of the story is that these issues are not unique to mashups or external services; they happen with internal services and full-cost vendor applications all the time.

[Charlie Wood]

My favorite example of Web 2.0 technologies in the enterprise is (as you might imagine) Spanning Salesforce, which lets Salesforce.com Enterprise Edition users subscribe to their leads, opportunities, support cases, documents, and now attachments, using secure RSS.

The fundamental benefit is that users don't have to go to the application to get at their data; instead, the data comes to them, whether its through their RSS-enabled web browser, a standalone app, an Outlook plugin, or their mobile device. The service uses RSS 2.0 enclosures to deliver documents and attachments so users can have offline access to not only their data but also their documents.

Let me know if you don't have an SFDC Enterprise account and I'll set you up with a demo login.

-Charlie