SOA Pitfalls

The Top 10 SOA Pitfalls series is a really interesting read. It reminds me of my first hand experiences of some of those pitfalls.

I was in charge of the solutions for a high profile project in a large Telco environment. In this particular environment, there were myriads of small systems which did not talk to each other. Reason for the proliferation of many small systems is that each department head can approve projects below certain budget. So each time a department/group has some business requirements, the tendency is to have a chewing gum and duct tape solution as long as it stays under the budget limit for the department head. So after years of such practice, users were left with small systems that were small in functionality and an overall complex enterprise systems environment for any IT architects.

The client had come to their senses to change this by introducing a COTS. Part of our project's responsibility was to replace those small systems with the COTS. After initial study, I found that we had to replace 7 small systems and integrate with 17 others. In this environment, a SOA platform is called for. Fortunately the client had corporate license for SeeBeyond (now called JCAPS after Sun bought it). JCAPS had been used in several other high profile projects ($10Ms, 1-3 years implementation time). To my astonishment, each of those project had its own instance of JCAPS running; and these instances were not talking to each other. So it looked like our project was going to introduce another instance of JCAPS silo! This type of use of EAI defeats the purpose of using EAI. After all, the 'E' in EAI stands for 'Enterprise' - it is supposed to be enterprise wide. After some hard fighting, I am glad to say that the project had a happy ending.