NOTE: Of late, I have been getting requests for very trivial problems that many of you are facing in your day-to-day work. This blog is not to solve your "project" problems - surely not a "Support" site.
I just love to share my knowledge in my spare time and would appreciate any questions or feedback on the articles and code I have shared. I also do appreciate thought-provoking questions that would lead me to write more articles and share.
But please do not put your day-to-day trivial problems here. Even if you do, you most probably would not get a response here.

Search This Blog


Monday, 31 December 2007

Service Oriented Architecture


I am an Architect in the Software Industry. I know the need for such a role is hotly debated one. But for now, I can do with such a designation.

Service Oriented Architecture is a buzz-word since almost 3-4 years now. I believe that it has not caught up as fast as it promised to. However, there is definitely benefits that can be derived out of its implementation (if done right) across large enterprises.

My opinion on this is that it is almost a sure failure, if it is taken up in a big bang way for implementation. It has to be planned and taken up in phases with calculated but less risky applicaitons initially. Once the technical success of it is ascertained, the applications of business value need to be taken up to move towards this architecture.

Though lot is said about this in various forums, I am yet to hear anyone say confidently that much of their enterprise has taken to SOA.

Anyone's thoughts on this?
Do you think Business critical applications should be taken up to prove the business value to the enterprise for a pilot phase or less critical applications should be piloted, to absorb and risk of failure?


  1. Gr8 thoughts, I had earlier (a year back) implemented SOA in conjunction with ESB (Enterprise service bus)

    Requirements for a service-oriented architecture

    1. First and foremost, leverage existing assets. Existing systems can rarely be thrown away, and often contain within them great value to the enterprise. Strategically, the objective is to build a new architecture that will yield all the value hoped for, but tactically, the existing systems must be integrated such that, over time, they can be componentized or replaced in manageable, incremental projects.

    2. Support all required types or "styles" of integration. This includes:

    o User Interaction -- being able to provide a single, interactive user experience

    o Application Connectivity -- communications layer that underlies all of the architecture

    o Process Integration -- choreographs applications and services

    o Information Integration -- federates and moves the enterprise data

    o Build to Integrate -- builds and deploys new applications and services.

    3. Allow for incremental implementations and migration of assets - this will enable one of the most critical aspects of developing the architecture: the ability to produce incremental ROI. Countless integration projects have failed due to their complexity, cost, and unworkable implementation schedules.

    4. Include a development environment that will be built around a standard component framework, promote better reuse of modules and systems, allow legacy assets to be migrated to the framework, and allow for the timely implementation of new technologies.

    5. Allow implementation of new computing models; specifically, new portal-based client models, Grid computing, and on-demand computing

  2. less critical applications should be piloted

  3. I like your blog principle.This is one of the wonderful post.This is one of the good understanding post.
    Android app developers