Surely, most enterprises have dabbled with SOA by now. Some have seen successes, and many probably haven't. But definitely, the promise of this enterprise wide services infrastructure with on-demand-changeable biz processes is not a reality. Sure.. these are functional in pockets and narrow usecases. But it is a far cry from the promise of 'any biz analyst being able to compose new processes'. Enterprise IT is not that frivolous- that a new process can be defined on the sly!
Consistent with this is the statistics quoted by IBM SOA Marketing head that in a study commissioned by IBM, found that companies that implemented SOA increased revenue by 2%. While this is encouraging, not sure if this study counts the many other botched attempts at SOA adoption- often warped as 'pilots'. I know of a major nation wide e-governance initiative in India that is languishing after nearly four years just because of the sheer overload of considerations, specifications and free 'advise' from vested interests (read the vendors)! What was to be a simple repository of e-gov services to enable G2G and B2G interactions, is yet to really take off. The same is true even in the enterprise scenario. The information overload faced by enterpirses is nicely captured in the presentation on ebizq (courtesy ebizq & ElementalLinks):
Where there are well defined point problems, SOA makes a successful entry and generates results (and tangible financial gains). These maybe in specific supply chain flows or in any other biz flows, or even in just management visibility into business processes/functions. As opposed to, 'lets first create services, let all IT apps make services available- and then see how they could be used'. This results in huge upfront costs, and major disruption in current IT initiatives, with no tangible results- as the results are dependant on identifying those point-problems that SOA will solve. The gains would be significantly better, if point problems are identified first and solved, before embarking on an enterprise wide initiative to create services.
A pragmatic approach, like I have said in the past, is to take a combination of top-down (point-solutions) and bottom-up (services first). As much as there is a need to identify point-problems that SOA can solve, and demonstrate tangible successes, there is also a need for each of the IT groups and apps to be SOA aware for ensuing SOA successes. The latter needs the individual IT groups and apps also to buy into SOA (the bottom-up part).
Hopefully, 2008 should see more of this happening.
