Is SOA Expensive: Reality and the Myth?
Industry is adopting SOA more and more. CIOs are under tremendous pressure to show the value of SOA to the Business. Business is asking more and more questions about the benefit of SOA. To Business, SOA is too expensive and does not bring enough value to business early enough (long gestation period). So CIOs are asking several questions around SOA to the technology service providers in search of a convincing answer and one question keeps getting repeated ‘Is SOA expensive – if not how and why?’
There is no straight answer to this question. One could argue for both sides of the camps and still make conclusion on either way. Let’s see why SOA is considered to be expensive by the people who are not so close to IT. There are several factors why SOA is perceived to be expensive (I would say only ‘to begin with’). But, remember SOA is expensive at the ‘beginning’ as there are few upfront investments required on Software Licenses, Infrastructures, Training etc. The lists below are the key areas of investments:
- Service Design: Making a component re-usable is typically 2.5 times more expensive as compared to having a piece of code which wouldn’t be re-used at all having the same functionality. This means when we create a Service we have to ensure that it’s going be re-used at least 3 times in the future.
- Software: Need additional investment in software – ESB would be one of the biggest piece, Repository and Registry (SOA Design and Run time Governance), SOA Testing, Service Management and Monitoring etc.
- Hardware: Additional infrastructure needed for all the above components. Although in the current commoditised hardware market this is not going to be a big dollar number compared to the Service development and Software License investments.
- Training and Enablement: Training IT personnel to enable them for SOA.
- SOA Governance and COE setup: To centrally manage the SOA programme/projects
SOA reduces cost in all the projects within the enterprise throughout all the phases of the SOA SDLC when reuse (of Service) starts happening – Requirements, High Level Design, Low Level Design, Development/Build, Integration, Unit Testing, System Testing etc. The cost savings are in the range of 30% – 80% in individual phases.
However, there are few areas where the cost would increase everytime the reuse happens – Documentation, Training, Configuration Management, Programme Management etc. Although, the amount of increase in cost is negligible as compared to the saving achieved due to reuse.
After an organisation adopted SOA, reuse of Services increase year on year – e.g. 10-15% first year, 20-25% second year, 30-40% third year and so on – which would have direct impact on cost savings. More and more Service reuse means IT is slowing becoming an ‘assembly’ shop from a traditional ‘development’ shop.
On the flip side, one may argue SOA is not expensive even at the beginning. One of the most expensive piece of software is ESB may be considered as not part of SOA investment. Any organisation would need an integration layer irrespective of whether there is SOA or not. So why should I consider ESB as part of SOA investment?
Similarly, one must not consider Application Server or equivalent technology as SOA investment. Application Server is commodity these days and foundation of all applications/Services running within the enterprise. What about BPM? SOA does not mandate BPM – BPM can be there with or without SOA. What is left? What about Service Governance and Service Management Tool – these two could be the only pieces of software which are needed for SOA (although SOA does not mandate these, one can still achieve SOA without the tool).
The bottom line is - it’s the Architecture team responsibility to manage the perception of SOA within the organisation. All the investments required for an IT Programme is NOT because of SOA. Lets not relate everything happening in IT with the name SOA – then SOA becomes the obvious scapegoat when things does not go the way it should have been or when the cost significantly overshoots. IT has to keep in mind that Business has never been so close to IT. Business has far more visibility of what’s going on in IT as compared to 10-15 years back. I am not suggesting IT to hide on what’s going within IT from rest of the organisation but be cautious in terms of setting the expectations of non IT stakeholders. SOA is just another way of doing architecture which would enable IT to be more agile, flexible and business aligned.
SOA is NOT all about the technology. SOA is about making IT more mature while bringing all the ingredients (People, Process, and Architecture) together and making those work in a more predictable (Governance) way which has been missing in IT for years.
