Business Ecology Initiative & Service-Oriented Solution

In the last Oracle Magazine (March/April 2009), David A Kelly has posted an article "Integrating Applications" about acceptance of the integrated solutions from Oracle. He's concluded that "SOA is attractive to organizations that need to integrate applications and business processes that cross departments or IT boundaries." I am afraid that Mr. Kelly has got into the same trap as one of Oracle's customer who called Oracle BPML Process Manager an SOA component (in the same article). Why would anybody need service-oriented architecture to integrate any applications, across IT boundaries or inside IT? Why Application Integration Architecture (AIA) is not enough for the task of integrating applications?

By the way, the same article has an insertion where Hasan Rizvi, Oracle senior vice president of product development, comments on Oracle Application Integration Architecture. How many times Mr. Rizvi mentioned SOA in the context of AIA? No one time. And it is quite comprehensible because what is oriented to service in the integration of applications? To me, mentioned Mr. Kelly's expression puts SOA up-side-down: there is no such task as integrating applications across IT boundaries. Instead, many organisations have a real life task for SOA - to operate with business services that cross business process boundaries in and out of IT. Solution of this task may require application integration but it is a very low level technicality.

After all recent acquisitions, Oracle is, probably, in the best position to raise the banner of service orientation concept and clearly articulate that implementation of this concept might need specialised SW tools, systems, and even technologies but service-oriented architecture is the architectural style, not a technology. SOA can only direct IT Development function to implement self-contained autonomous business services and their compositions/collaborations that may require an integration work. In other words, SOA, following the concept of service orientation, defines WHY business or technical service should exist, WHAT such service should be, and WHO is expected to use it. AIA, in turn, dedicates to HOW the services may be constructed in given enterprise execution context. At the same time, integration itself does not constitute any service orientation even if the integrator uses Web Services technology that provides standard-based integration interfaces.

SOA realises the concept of service orientation in the architectural level; it is applicable to both Business and Technical architectures. To implement those architectures, a lot of things have to be changed in the IT organisation. For example, the ITIL v.3 has re-defined process-oriented IT functions into the service-oriented manner already. This is the first step (besides OASIS SOA standard) that outlines the fact that HOW we doing things, being still very important, does not necessary provides for WHAT to be done and this can mislead IT resources. The same ITIL v.3 together with the concept of service orientation crosses IT boundaries into Business and points that the essence of Business is in the business services while the business processes are only particular implementations of those services and, because of that, may be changed or even discarded at any moment.

Having the full stack of IT technologies in hands now, Oracle can reconstruct it in the way that promotes service-oriented view on the IT life starting from the Enterprise Technical Architecture and getting to the last 'dot' in the design, implementation, and support of IT products. Oracle can make SOA and AIA work well together but if somebody would try to substitute one of them by another, even Oracle will be unable to help avoiding very poor results.