How expensive is offshore? Some things are better done than described....

Do companies out there go offshore for cost reasons or because they want to improve their time-to-market? Are they aware of if reducing costs it will take longer in time and when optimizing for time that it will be more expensive?
I just pasted interesting questions from Michaels comment to my last entry about offshore activities.
It is not possible to practice offshoring without have an answer to these questions. Before the project actually starts these questions should be answered in "vision" or "mission" document. It seems like, some big companies (almost institutions :-)) do not have a dedicated strategy. They only want to offshore some amount or percentage of projects. The obvious reason is saving money (but the real reason is often the reaction of the stock market to offshore intention).
But this reason is too general. From my point of view development is LESS expensive, than maintenance. So it is not very smart to save money in the development, and ignore the maintenance. The general requirement "Saving money" has to be refined in the vision or mission document (but no more than one page :-)). I suppose, companies would like to save money in general, and not only in the development phase. In this case the maintenance and not development becomes important. But this changes the requirements for the development phase and especially the non-functional requirements. To save money with offshore in the maintenance phase the following points have to be considered:

  1. The architecture of the system has to be defined by internal/corporate developers/architects.
  2. Naming conventions, patterns, approches, documentation style has to be defined and are essential.
  3. The offshore environment (IDEs, servers, software, os, load tests) should be identical to the corporate environment.
  4. The continuous integration server should run onsite, not in the offshore companies. Especiallly the fraction during deployment can be so minimized.
  5. Internal developers should review the code AND have the power to refuse the results of some iterations because of violation of the defined rules and specification. The amount of automation depends on the fomalisation of the archtecture.Tools like: pmd,checkstyle,findbugs, jdepend can help to track the quality but cannot replace human reviews.
  6. Errorhandling and logging strategies should have "bullet-proof" quality.
  7. Monitoring, management and deployment strategies should be defined and reviewed.
  8. A blueprint should define the amount of allowed frameworks.
In best case the whole structure of the software with naming conventions, architecture, patterns, etc. should be defined and continuously observed. Most of the projects I saw, didn't consider this points, so there was no defined structure in the software. The software  was in rare cases cheaper in construction, but always more expensive in the maintenance. Some of the projects were cancelled because of this reason. I would say "Some things are better done than described...." or even "Some things are better generated than offshored....:-)".
I was involved in one offshore project, which was really great. I would like to discuss this in the next part.


hi adam,

thanx for bringing some light into the offshore thing. i really look forward to reading about your one great offshore project. what did that project make it so great? what was different from the other offshore projects you have been observing or being a part of?

one thing on your list important for successful offshoring (if you go for the overall cost-saving goal), i think is really hard: the infrastructure. how could you possibly recreate an environment at some offshore location that is more or less similar to the environment that the application to be developed is designed for: the environment when going to production.

there are databases with possibly sensitive information, there are other services that the application might depend upon, and you might need to get some software installed at the offshore location which might heavily bite into your budget due to licensing costs - at least if you care for copyright and terms of usage.

so the problem i come across is: is offshore right for you if you heavily depend on infrastructure that is difficult to reproduce at some offshore location? are there alternatives or best practices for how to deal such a situation?

an obvious solution could be divide an conquer: slice the application into well-defined subsystems. but then, you will have to put even more emphasis on the architecture and design as you will have to do the integration of all those subsystems which is very likely to take at least one feedback iteration loop and not turn out to be perfect at the very first trial.

anyway, looking forward to reading more on your blog. i will definitely stay tuned ...


Posted by Michael on July 21, 2006 at 12:56 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments