Desktops with gigabytes of RAM, Handheld devices that work like computers and an SOA compliant enterprise do not evoke a reaction these days; they have become more of a given thing. Today everybody wants to have an SOA compliant architecture without giving much thought about its applicability and ROI but Let us keep that discussion for another day. Let us assume that you have a good case for SOA and it actually makes sense for your enterprise to be service oriented. Now, the only question that needs to be answered is how to find out that if you are getting the right stuff.
Let’s take an example. Suppose I run an Insurance company and right now I sell policies only in my branch offices using a very sophisticated and expensive core system. Now my business teams comes to me and says, “Abhishek, in order to grow our revenue, we need to have a website for selling policies directly to the end customer.”
So, I go to my core system vendor and ask them to expose a web service which can be integrated with the website. These people come back to me and say “Since you are one of our valued customers, we are going to expose ALL the functionality of the base system in a single web service so that the web site can have the full functionality of the base system.” Is my vendor doing me a favour or setting me up for failure?
When you look for a technical solution, most of the times, the simplest solution is the best solution. You need to understand what your short term and mid-term goals and figure out how to address those goals. There is point in creating a system that is going to last for 15 years but is going to be a pain in the neck to maintain. The other aspect that you need to look at is, are you going to use all the functionality of the base system? (Yes, there is a finite chance of a nuclear powered world war, but do I need to build a bunker instead of a house?). My product vendor is giving me this option because he wants to cut corners in development and pass his half baked, high maintenance ‘SOA Compliant’ web service as a state of the art system. Instead of taking a more granular and systematic approach to developing web services, the vendor is planning to expose his current, internal methods as web service which is going to save them development effort, but with quadruple the effort for integration and then later maintaining the services.
From our experience in working with different customers on SOA enablement, we have come up with a quick dipstick to evaluate if you are getting a lemon instead of web services:
- Granularity of Calls – If the call is too fine grained and is expecting you to pass more than 10-15 parameters, it is not a neatly designed service but a legacy code in disguise.
- Content of the Web Service Message – A lot of legacy system which used messaging queues extend the same mechanism to web services – methods accepting XML strings instead of Objects. This has significant transformation overheads and also do not utilize the out of the box web services validations.
- Documentation – Most unplanned web service implementations come with zero documentation. If you get sample input/output instead of a document, think twice before starting implementation, you are in for a long haul.
- Error Communication – When you hit a error on the server side a well written web service will give you an exact error code and an explanation of what just happen, for instance – “ERPRM012: Unable to calculate premium as insured value is null”. A lemon, on the other hand will give you –“ Unable to calculate premium” or worse –“Error processing request”
- If it is too good to be true, it isn’t!
Though, these are simple and intuitive things to follow, yet you come across so many systems that do not pay any heed to any of these checks. Integration is one of the more complicated aspects of system development and an ill designed web services can significantly increase your Cost, effort and time spent during integration and during the maintenance period.