SAP and Oracle - what do you own, what do you rent?

One effect of the package vendors, mainly Oracle and SAP, taking up SOA has been the relentless charge in the number of "services" these companies claim to deliver. Thousands of services are being claimed already by these folks and they both have effectively the same strategy namely:

Middleware on a package, not the world's most advanced architecture but its certainly a start. Both are talking about moving processes into the middleware layer and both are talking about the package becoming the basic services which are then orchestrated in the middleware layer.

What this does mean is that package development is shifting already, and will shift even more in the coming years. If you take something like Salesforce.com as a model in this area, and think about what these packages normally represent then there is another way to think about the diagram, namely that packages represent the capabilities and the real services will live in the middleware. The reason that SAP and Oracle are claiming thousands of services is that they are taking a fine grained approach to what a service is, namely just exposing what they have. This means that to create a proper business architecture on top of these things will require you to moderate access to the package via the middleware.

With SAP pushing Process, and Oracle always struggling to get beyond data, its important that businesses look at how the represent these packages in a way that suits them. Central to this is the idea that the capabilities of the package should be left untouched (as package modification is always a dangerous thing) while your business service architecture should be realised in the middleware.

So don't think of buying Services from Oracle and SAP (at least not yet) think of buying capabilities from them that you can construct into Services. In this way you can get the advantage of standardisation and commoditisation without having to completely adapt your view of the world to the package. A package should commoditise the capabilities of an organisation where it is used, the service should provide a business correct view onto those capabilities.

What all this means of course is that the real value in this world is clearly split. The package represents the reduction of cost by selecting commodity capabilities, while the middleware represents both services the package delivers and the higher value services which undertake orchestration across those services.

So as with Salesforce.com, it begs the question with Oracle Fusion and SAP. Why would you own the package? If you aren't modifying these capabilities but just want to access and orchestrate them in your own way (i.e. provide services) then the only bit that is unique to you is the middleware.

ASP models have been tried before with SAP and Oracle and had variable success (to be kind) mainly because both the capabilities and the configuration was done in the same environment, this made the work harder. With these new models we are able to think about having a clear split, with the package being about capabilities and the middleware being the piece that provides access to it. In that world you don't need to own the package you just need access to the package's capabilities. And if you can drive towards accepting those capabilities as they exist out the box (i.e don't tweak the package) you can reduce or eliminate the traditional upgrade challenges.

As Oracle and SAP move more of their orchestration and (hopefully) start creating proper service functionality within the middleware the dynamics of package development will have been radically altered instead of being a single great big blob it can become a question of:

Rent the capabilities, own the services.

Technorati Tags: SOA, SAP, Oracle, Service Architecture