"1 out of 7 SOA implmentation is a failure and 6 are on the way"
This is not an article on the concept of SOA, but I wanted to stimulate the thinking process of the people who wanted to build solutions based on SOA. This can be applicable to choose any technology and is not specific to SOA.
Choosing the Technology
Given a business problem how do you choose a technology or framework to build a solution to the problem? This is a big question to answer but most of the time the application development and support industry go with the "Current Hot Technology" and choose it as a platform for building the solution. So what is wrong with that ? in developer voice "Technically anything can be done with any technology". Below story can help you understand this more.
The "Cosmopolitian" Construction company architect Tom just visited Finland where he was amazed by the "escalator" transportation system that carries people from mountain to mountain. He was so inspired by the solution and wanted to try similar solution in his projects. he learnt the technical details of the implementatin and even trained people on his company for future assignments. Now he got a contract from one his customer organization to provide a transportation system for carrying the employees from main branch office to another branch office. Tom decided to do this assignment using the escalator technology. he discussed the idea with team and management and everybody appreciated for coming up with such a cost effective idea for long run and they have even consulted their customers with the idea. As usual the customer response was "I don't care, I need a solution. As long as it works I am happy". Now in the team meeting one of the team member raised a question "The escalator idea is great, but we don't have mountains here. so what we do?". Ok "that is a good point" replied Tom, "but how about building a tower in both the office and that might solve the mountain problem". So we need a POC to illustrate this and the team did a POC with two small towers they are just few meters apart. The POC was very successful so they decided to go with escalator technology for solving the problem.
Now do you think they will fail in the implementation? if yes why? and if not why? [ Remember technically anything can be possible :) ]
Note: during the implementatin phase the team just came to know that the main office and branch offices are actually located in two different towns!.
Evaluating the Technology
Most of the cases adopting a new technology go through an evaluation and "Proof of Concept" stage, but most of the time the people who evaluates it will look at the feasibility of installing, configuring and probably running a "Hello World" type of application in the organization specific environment. If it works out then it is evaluated as a successful POC. Is this enough to decide a technology for building a solution?
Guidelines to choose a technology
1. Remember that Technology solves a specific business problem. So before learning any technology you must understand that what is the problem it is resolving. if you are having a very good understanding of the problem domain of the technology then your job will be mapping your requirements to the problem domain. If your requirement is not fitting in the problem domain of the technology then it is better to choose a different technology that solves your problem.
So let us take a look at what is the problem SOA solves? you can find lot of articles about this and I am sure you will find two vast problem domain "Business Process Management" and "Business Performance Management". The important point is that look at your requirement and map this to the BPM problem areas. If it is not matching then do not choose SOA Platform for building the solution.
Most of the time developers say SOA solves the problem of "re-use". According to me this is not true, "re-use" is inherited in SOA style and design but it is solving a different problem.
2. As I mentioned earlier, evaluating technology, most often lead to building a hello world sort of application and infrastructure feasibility. It is important but you should not stop your evaluation there. create a context similar to your business problem and do a POC around it and then analyze the feasibility.
Remark:
One of the biggest toolset for a designer and architect is to keep up a catalog of "Business Problem Domains" and the technology that solves the problems.
enjoy!
