The South East Asia SOA Weblog

During my presentation in the “Application Integration Architecture of Excellence” at Sari Pan Pacific Hotel, Jakarta, several questions were asked by the audience related to how much coding and technical development work is required by one organization if they want begin their transition towards SOA. See presentation slide in SlideShare

| View | Upload your own

The develop-and-deploy paradigm of most IT technical people needs to be changed in light of the re-usability spirit promoted by SOA. SOA is about re-using existing application functionalities and services which have been proven to perform business functions well, then integrate them into an orchestrated service to perform business process. So, the question should not be how much should I develop? It should be how much can I re-use?

When new functionalities are required, an organization can be presented with two options: purchase the packaged application to perform the required business function or develop the application in-house. If purchasing packaged application is opted, then SOA can set the standards for the new application, it has to be SOA-ready (a.k.a. to some technical guys may call it support WS* standards). SOA-ready applications are ready to plug and play to the enterprise service bus, which is the integration backbone of the organization, the effort to integrate it will be relatively minimal. If the organization decides to develop its own application to serve the required business needs, then they need to bear the MVC framework mentality in mind (See: http://en.wikipedia.org/wiki/Model-view-controller). Clear separation between Model-View-Controller has been proven to clearly distinguish business functionalities from the underlying data model and the presentation codes. These business functionalities, which is the “C” in “MVC", can then be aggregated into business services that can be plugged into the enterprise service bus. Without clear separation among the Model-View-Controller functionalities, the newly developed application will be difficult to be service-enabled.

The message delivered by SOA is clear: re-use whenever you can, only develop if you really need to, this will save time and cost, this will enable application delivery faster and cheaper. The integrated services will set the necessary ground for future composite applications built re-using current functionalities. This places more importance on proper SOA management and governance to make sure that service discovery and management can be done efficiently. The ROI of the architecture may not be instant, but in the long run, it will make business more agile and more efficient if done correctly.

I will have the privilege to speak on behalf of PWS Consulting Pte. Ltd. in “Application Integration Architecture of Excellence” on June 24, 2008 at Sari Pan Pacific Hotel, Jakarta.

The event is a Lunch Executive Meeting held by Oracle, CTI and PWS Consulting that will discuss about Oracle SOA Suite and how it can help answering the business and IT challenges faced by financial institutions today through SOA and how the technology can bring the architecture to realization. Accompanying me will be my old friend, Mr. Allan Darrell (LinkedIn Profile) from ORIX Indonesia Finance who will be speaking about successful SOA implementation in his organization.

Hope to catch you all in the event!

In a recent observation made by Bruce Silver in Intelligent Enterprise (http://www.intelligententerprise.com/blog/archives/2008/06/the_future_of_b.html), he talks about the future of BPM at Oracle/BEA after the acquisition.

Bruce made an interesting observation about two points of view of looking at BPM solution, one is from integration middleware perspective, the other is from optimization of workflow and business performance.

It looks to me that one is looking at BPM bottom up, while the other is looking at it top down. Oracle and BEA adopts these two different point of views for BPM. Oracle’s approach is more towards looking at BPM from integration perspective, transforming enterprise applications from old-style monoliths to composable services. BEA sees BPM from the straight BPM perspective, from workflow and business performance optimization perspective.

At this point, it is too early to tell what approach will be taken by the Oracle/BEA BPM offering. Bruce Silver predicts that it is possible Oracle will maintain both product lines while still figuring out what to do with them. There will be a Webcast on July 1st 2008 by Oracle President Charles Phillips and Oracle Senior Vice President Thomas Kurian that will explore about the addition of BEA products to Oracle Fusion Middleware. We shall then see what will happen…