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:
- The architecture of the system has to be defined by internal/corporate developers/architects.
- Naming conventions, patterns, approches, documentation style has to be defined and are essential.
- The offshore environment (IDEs, servers, software, os, load tests) should be identical to the corporate environment.
- The continuous integration server should run onsite, not in the offshore companies. Especiallly the fraction during deployment can be so minimized.
- 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.
- Errorhandling and logging strategies should have "bullet-proof" quality.
- Monitoring, management and deployment strategies should be defined and reviewed.
- A blueprint should define the amount of allowed frameworks.
I was involved in one offshore project, which was really great. I would like to discuss this in the next part.
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.