It’s unfortunate, but Vendor’s, SI’s and VAR’s regularly mis-sell SOA.
Let me give you one simple example…
About 12 months ago during an RFP demonstration, a big name software Vendor suggested that their “3,500 ready made services would deliver SOA out of the box”. They even claimed that somehow 3,500 services was a mathematically optimum number an implying that everyone would need this number of services eventually- so why try and do it yourself?
Clearly this promise of a ready made service inventory could be very tempting to the uninitiated – but it’s just plain wrong. It’s like someone dumping a keyboard with 3,500 keys on your desk and then telling you that it can make you type faster. It’s simply not true.
In reality this particular vendor’s API had more likely been the result of a quick and dirty hack to expose an old functional API as a bunch web services. They could do this by simply turning each ancient API function into one operation on one web service. But the resulting service inventory would be a vast and unfathomable hodgepodge where every service API was designed at the same level of granularity and with the wrong level of coherence (both OO terms but they’re appropriate here). Ultimately this leads to an implementation nightmare where a considerable amount of complex service composition would be required in order to perform even the most basic of tasks.
Furthermore, regarding the 3,500 web services is optimal claim, the only math that I’m aware of that would make a difference to service interface design is Partition Theory and Partition Theory quite clearly states that a simple 1:1 mapping of services to operations (like those in this particular API) is very rarely the optimal arrangement and would more likely lead to highly inefficient solutions.
When challenged about this, the vendor’s ‘ingenious’ solution (I’m being generous here, I actually mean ‘demented’) was for the client to licence some more of their SOA tools to help with the burden created by this massive inventory of services. They’d need a registry to help with the discovery problem and a process management tool to help develop the large number of service compositions they’d need to build to do anything useful with their 3,500 services. This would of course require additional capital outlay, infrastructure and training and would inevitably deepen the vendor lock-in even further.
Fortunately, my private sector client at the time did evaluate the situation correctly and didn’t take the proposal any further. However, in less experienced teams this kind of mis-selling could go completely unchecked and could end up costing organisations a small fortune in scope creep and additional integration and implementation effort.
So what’s the solution?
I’d like everyone to understand this simple fact and use it to their advantage:
SOA can’t be packaged and sold!
The only way to get an architecture that is naturally service-oriented and fits the way that your business operates is to design it that way. There is no such thing as a pre-packaged SOA that can be bought off the shelf. Service-oriented solutions need to be designed by you, for you.
Vendors, SI’s and VAR’s currently find it all too easy to exploit customers who don’t have an expert SOA practitioner on their team. So my advice is for you to do yourself a favour and go and get one as soon as possible. It could be the best decision you’ll ever make and given the prices quoted by SOA vendors I’m confident you’ll see a phenomenal return on that investment within a very short space of time.