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.