Well, the title of this post is bit exaggerated, SOA is definitely good but implementation is hard and a number of times we end up in creating a mess, took ages to develop but failed to deliver success.
What is good about SOA?
As we know when we say SOA we mean that we need something that would be driven from business model and functions, would reuse existing functionalities with minimal impact on existing applications and making them interoperable with other systems so that we could save time in redevelopment in future.
Also when we develop new systems for future we attempt to make them 'SOA Ready' i.e. designed in a way that any business function can be made available to other systems/consumers without or minimal coding. Of course the idea is fascinating and it does work.
so what doesn't work?
Here the problem I want to address is that having a vision of SOA when technical people sit together and design a framework + lifecycle for the entire business apps and then if they force all development work to follow the same framework for all new developments in order to have consistent development practices, SOA ready applications, potential long term time saving in new developments, etc, there are some serious issues arise from application delivery perspective, particularly slow delivery of solution due to huge investment of efforts upfront for making applications 'SOA Ready'.
But do we really get all those benefits in future? The answer is context driven i.e. it may be or not depending upon the nature of business and development projects. But what I have seen a number of times you can not apply one solution to all your problems.
Take this example, you have got a very nice framework, a framework labelled as SOA based framework, with all nice components, this block, that service, this interface, that data contract and this and that etc. Now you have got a small application to develop for a small group of users in your environment. Would you go for an SOA ready application?
The mistake, in my opinion, people make is that they will go straight after a SOA based architecture while in principle the application is not a right fit for SOA. They do it becuase it is the standard architecture and practice of the organisation now. As a result, developers spend a lot of time in fulfilling framework requirements by developing interfaces, layers, services etc with very less probability of any reusability in future.
so what to do?
In my opinion whenever we design a SOA ready framework we have to consider following points
1. First SOA based architecture should not be a mandatory for all new applications to follow
2. Every application will have to be evaluated to see if there is any real benefit in developing it as an SOA ready application. This depends a lot on how business processes work and not the technology. If the new application is for a small group of users, who are working in isolation with less probability of exposing their functions as services, then we can use very simple architecture and forget complex SOA based architecture.
3. Also, the framework should have pre-defined cut down versions for medium and small applications with lesser number of layers/services/interfaces in order to reduce development overheads. The application will be judged and right model should be picked and applied
4. If using agile methodology, then future reusability can be left over to refactoring. What I mean is that instead of investing time today, leave it to the time when it is required to expose its services and at that time refactor the application and deploy it as an SOA service.
5. As a general rule core systems should be strong candidates of SOA style development. For example, customers database, core sales operations, main financial systems etc. While the systems like some feedback capturing application, some monthly computing application with short expected life span (2-4 years) etc are bad candidates and should be developed in a quick and easy way.
in summary,
We should focus more on delivery without investing too much time in provisions for 'future reusability scenarios'. For instance, once it happened to me that my team put a lot of effort in developing an application with SOA based architecture and ending up with the situation where business users discarded the application, never went live as the business owner of the application had left the organisation and the new owner did not see any real benefit in the application. All our efforts for a 'highly flexible and reusable service based SOA style' application go in vein.
question to ask yourself,
So next time you get an application to develop, ask yourself, does it really need to be developed as an SOA application?
