The real problem for Business SOA comes from matured outsourcing companies. Apparently, such outsourcing companies try ignoring or omitting the aspects of service orientation in their implementation to minimise their hassle despite you have provided them with concrete and clear documentation on what you need and how you want it to be done (in SOA). They even ready to use (pay for) their architects to re-write your architecture and the high level design; they do anything just to simplify their work. Moreover, they do realise that the products constructed in the service-oriented style will work 'today' and 'tomorrow' without significant involvement of IT, which, certainly, decrease the outsourcing needs for particular client in the near future.
I am talking about current tendencies in overseas outsourcing. The situation reminds me not rare case where guests who are invited into your house to stay over several nights start to behave like the house-owners overnight. As we know, SOA is not a technology; it is a methodology that requires a particular approach and operational discipline in implementation. Moreover, nobody can buy SOA; it must be build internally because it has to reflect real needs and tasks of the enterprise's business. All this means that when you hire an outsourcing provider, you must have two things 'on the table':
1) clear understanding about what you actually want in the service oriented solution (business needs and requirements);2) well articulated expectation of how you want the things to be done to fit with your constraints - technical and cultural.
Of course, you can hire an outsource vendor to formulate both of the above but this vendor must be fully reliable a long-time known 'fellow': you have to trust it some of your corporate internal secrets to formulate real needs of your business.
For the last 5 years, we see a rather negative to SOA trend emerging in outsourcing. Particularly, many mature outsourcing companies do not want to do "whatever work" as they did before but they are, probably, not arrogant; in reality, they are now too big to do "whatever" client wants and they may have economies of scale on the back of their size and internally standardised methods. Unfortunately, whatever reasons are they do not really help you.
Well, how does this affect SOA?
Here you are: to preserve their economies, the outsourcing companies want to obtain a full control over the work they do, and I cannot blame them for this. However, there is a very high probability that their 'control' does not count the SOA solution you have constructed for your company. Why? Because as any distributed and flexible solution SOA requires more initial work; some parts of this work is unusual to traditional SW development, which demands additional training, special tools and more attention from the Architects and Management. For example, SOA implementation requires a lot of thinking and design up-front in the manner of services/functions rather than in objects (but the work of Architects is expensive); not all object-oriented development practice may be applied in service-oriented development/ testing and developers are getting under the pressure that they resist somehow. Implementation of real SOA is a new thing for traditional outsourcing; it requires extra efforts on the delivery side, which is not usually welcomed in settled companies.
Continuing this line of new relationships, the outsourcing companies have started to offer a partnership with the client companies more frequently now. These offers target a full outsourcing of the client's IT. The outsourcing companies do promise to meet your business needs but in their own way. As any independent company, the outsourcing company is interested in its own revenue first of all, and there is nothing wrong with it. However, their revenue is not your first interest. Recall the Forrester's conclusion at the beginning of the Part 1 - your business heavily depends on the technology, i.e. when outsourcing your IT, you outsource a part of your Business. Then, it is just a matter of time when your Business gets acquired in full. Is this what you want when negotiating outsourcing of your project the first time?
So, what can we do to have our SOA done right for us? Here are a few advices:
1) Prepare/design/organise your SOA solutions by yourself or with a trusted consulting company. This company should be responsible for constructing the things right for your business and for you;2) Find and hire an independent testing/QA/ IV&V company with several years of experience in SOA system testing using such tools as iTKO Lisa or Parasoft SOATest (these tools are designed with a deep understanding of what SOA is about and allow for the end-to-end testing of SOA Services);
3) Find an outsourcing company and try to put your SOA solution into the contract with serious penalties against violation of Your solution. If the contract is considered by your legal service as not the best place for your SOA solution, make sure it gets in full into the Project Requirements. The latter may not be reviewed by the outsourcing company but explained to the outsourcing company as the conditions of engagement;
4) Put a lot of attention on the development skills offered by the outsourcing company. The cheapest company is not necessary the right one for building your future (SOA solution). Also, no technology vendor's recommendations may be a constraint for the SOA solution - SOA is technology agnostic. If the outsourcing company says that selected technology vendor interprets your technical vocabulary differently, require that your semantics to be used in the engagement unless you are convinced that the vendor's proposals serve you better;
5) All deliverables from the outsourcing company must be verified and validated by your testing company and this has to be the part of the contract with the outsourcing company as well;
6) During the development process, watch for every requested change (Change Control Management) from the perspectives of the impact on the final result;
7) When under the delivery pressure, de-scope functionality rather than compromise services by the non-service-oriented implementation. For example, when developers say they will build a component and then expose it with Web Service, stop it; they have to define the service, define the interfaces first and only then build the component within the service boundaries. Also, a development traditionally worries about the code reuse but this is not a concern for SOA - it is interested in the function reuse and has to cut off everything that causes hidden dependencies in the code underneath.
I wish you to survive and enjoy your SOA solution in production.












Outsourcing has so many benefits:
1) Cost Savings
2) Time Zone Benefits
3) Quick Turn Around Time
4) Standardizing Business Processes
and many more....
http://www.outsourcewebsite.com
Well, this list of benefits is aging if not obsolete already. This IS the problem.
“Cost Savings� - This is illusive believe. It was before but not anymore, overseas outsourcing cost is rocketing now. Plus, if you count re-work and ‘strange’ bug fixing, the cost is pretty much the same as in, e.g. US rural regions.
“Quick Turn Around Time� – does not work for matured companies, there is no magic
“Standardizing Business Processes� – it is not clear to me what you mean by this. I am saying in the post that the standardisation in the matured outsourcing companies does not necessary fit with your standardisation, in your company. Since you have defined what you need and how, you expect that the provider you hire would do some job to fit into YOUR process and not other way around.
“Time Zone Benefits� – this is certainly good but if you cannot get what you want for your money , the work for 24 or 25 hours a day does not really matter.
I agree with Mike. I had worked in both the sides of the shore. I found that there is not always a very good relationship between the vendor and the organisation who outsource.
Cost Savings - You are right, when I worked as a vendor, project team members rapidly changed, with just few documents and few hours session to do Knowledge Transfer between the old and new team member and most importantly very under paid and not technically sound interns, in fact out of 5 members in a project team 1 will be a senior developer 2 will be very junior and 2 will be interns. This is true, and this is happening even now, for cost cutting the vendors offshore are doing even more damage by reducing the very junior to 1 and increasing the interns to 3. The interns had no training in Java or a quick training given in 3 weeks, all I could gather from them was that they can do command line programming with Java which could do mathematical functions and no idea of what J2EE or .NET is. We must understand the fact that these people will become architects and project managers in 5-6 year time. The end result is failure of project and sub-standard outcomes.
Another problem is false promises. When I worked as a Chief Architect for an insurance company, they accept a project without seeing the business requirement. The project manager just looked at the volume of the requirement document without consulting any business architects or Analyst and then assessed the project to be finished in 6 months, but the reality is that the project went for 1 year before it was accepted as finished. This I came to know when I visited the client and found out that the business requirements need to be elaborated.The elaborated requirementended up doubling the volume of the business.
It’s not only that, many Vice Presidents and Senior Managers of the vendors has no knowledge of new technologies and mislead the whole company, they will stay in their ivory tower of old IBM Mainframe/COBOL programming experience. I remember a VP in a vendor company telling that all the new technologies are pathetic and not good compared to the Mainframe/COBOL he knows when he was a developer in 70's. I do know the strengths of such legacy systems, but there is always a limit to what can be told to a team who is working on new technologies.
Also many outsourcing companies are "We will do anything and everything for you" kind. It is like you go into a huge flea market and find everything you need some are real and most are counterfeit. When I visited a vendor as a client later in my career I found that they sold their product which is based on J2EE with the help of a Systems architect who has done CISCO certifications and working on managing the company servers. I spoke with the Systems architect unofficially and found that he sold the product using the book knowledge he gained on J2EE in a week time. Later I found that the product is totally obsolete and was not developed further for more than 5 years and none of the people who developed that product was working with them. I have to stop my company to make a deal with this vendor citing these reasons.
I appreciate and recognise the fact that I was nourished and grew to the state in which I am now by outsourcing vendors, but when I moved to the side where I need to manage outsourcing, I couldn’t stop noticing the money poured by into this bottomless pit of no return called outsourcing.
Outsourcing is no more a magic bullet, you will require very strict governance to manage the outsourced projects otherwise I had seen most of them going in the wrong direction.
Also the vendors must stick to the list of technologies in which they are experts in rather than telling that they can do anything and everythign you want.
Thank you, Venkatesh, your experience talks the right things by itself.
Your comment is even more important due to your history of being on the both sides of the fence.
For a person who has worked on both side of shores Venkat, I must congratulate you on your technical prowess, because of which in-spite of being in teams like these you are where you are.
I have not worked in the outsourcing domain for more than a decade (am still on a learning curve). But to take up Michael's point that outsourcing corporation would not like to implement SOA as it would hit there revenue potential, does it mean that technology head of large corporations have no idea of what goes in conceptualizing a SOA and they are ready to give a complex piece of work to an entity that does not understand it.
To put across another perspective Infosys has a training center that it has built at a cost of more than half a billion dollar to ensure that the people who are put on client projects are up to its standards and this happens when Infosys hires 26,200 from a set of 400,812 applications and the training duration is One year.
Please do continue sharing these discoveries with individuals like me who still have to see this face of outsourcing......
Very interesting comment, MS. It seems you are well aware of the Infosys ‘homework’. A couple years ago, I talked with Infosys’s Head of SOA Pracrtice and got an impression (supported by followed Infosys publications) that their SOA practice was more technology-oriented than we need now in the companies to properly position our SOA-based solutions.
To your question, yes, too many Technology Heads, especially in large corporations, “have no idea of what goes in conceptualizing a SOA and they are ready to give a complex piece of work to an entity that does not� want to do it in proper or required way. This IS the problem and, I think, a new problem with oursourcing.
Thanks Michael.
In my opinion
a) CXO should always be business benefit driven, be it SOA, Cloud, ERP or any other technology.
b) SAAS and transaction based pricing model are going to be business model disruptor for both System Integrators and Software Product Corporations.
No longer large deployment with ROI after 10 years.
SAAS has additional disruption for the Software Product consuming Corporations. Modern market conditions change massively and frequently and the corporate business has to move accordingly. Since in many industries SW is a significant part of the business, existence of SAAS creates additional latency and inflexibility to the business.
Thus, SAAS may have only narrowed market for relatively stable, very traditional and slowly moving business types.