Internet-wide Services Integration Architecture needed now!

As I mentioned in a prior blog entry, the lack of a single consensus mechanism for different Software-as-a-Service apps to integrate with each other and with enterprise-oriented software applications (like SAP, Dynamics, Baan, Siebel, Oracle, Clarify and others) is a clear obstacle to the success of Software as a Service.

I would say that it has always been an obstacle to the success of the software packages themselves, but the SaaS viewpoint adds more fuel to the fire.

It is expensive and time consuming to create point-integration between every application and every other application.  In Enterprise Architecture, we attempt to address this by creating a canonical mechanism for communicating a single business event, and a shared enterprise service that serves as the interface for that event. 

In the Internet, we need the same thing.  We need the ability for a SaaS app to generate an event that an internal SAP instance can consume, including the ability for the SAP instance to call back to the SaaS app to get further data about the event or the data owned by that app.

Of course, if the SaaS vendor is Dynamics Live or Salesforce, then the SAP company has a conflict of interest.  After all, they have their own CRM solution.  Why would they want to integrate with a service-based solution and potentially create more competition for themselves.  Dynamics faces the same conundrum with respect to Dynamics AX and Salesforce.

To overcome this conflict, it is imperative that we begin, now, to embark on a new approach.  We need a single canonical mechanism for all enterprise app modules to integrate with each other.  If done correctly, each enterprise will be able to pick and choose modules from different vendors and the integration will be smooth and relatively painless. 

Why?  because if SAP uses 'Mechanism X' to communicate between their financials and CRM, and Dynamics uses 'Mechanism X' as well, then an organization can move from using Dynamics for both modules to using Dynamics for one and SAP for the other, or the other way around, readily. 

App developers: Think of it this way: The SQL Server management environment has been using a published API to talk to SQL Server for a long time.  (DMO).  Everyone knows that the API works, because SQL tools use it. Therefore, if you want to create a tool for SQL, just write to DMO.  You can replace one component and leave the other, because the interface is public and defended.

I would like to see a body be created to develop the public interfaces between the major functions in enterprise software, that the body doesn't move forward until a majority of major players in enterprise software sign up (including all three of these: Microsoft, SAP, and Oracle) and commit to supporting it, and using the interface for their own product modules to speak to one another.  The interface has to allow for SaaS modules as well as installed modules to both produce and consume events and data.

The lack of this consensus creates unnecessary inefficiency, vendor lock-in, and huge levels of waste in the IT business. 

It's the elephant in the room, folks.  Rosetta is a great start but they didn't have buy-in that the products would change to match the interface.  In effect, they created an expensive 'bag' to attach to the side of any product, but nothing that the products themselves were committed to adopting to communicate between the modules internally. 

Perhaps we need to threaten with legislation... hmmm...

Comments

• Anonymous
  December 25, 2006
  Just a thought here. When 3D graphics became more commonplace, the processing required to create them, being rather intensive, was moved to the hardware level. Perhaps Microsoft should be getting together with Cisco to build some of the SOA architecture into router and firewall hardware. This would encourage a move towards standardization, as well as speeding things up.