Most large system integrators have offshore development centers where most of the extensions, interfaces and conversion procedures are written.

It’s no secret that most offshore developers, while having a good understanding of the technology stack, lack practical experience and have little knowledge of how best to apply the technology to the business task at hand. This can create issues when faced with decisions regarding areas such as:

• How to avoid customisation in favour of extension
• What are the available extension points in the module being implemented
• What are the touch points with other modules.

This lack of practical experience can also impact the quality of the technical design they produce.

To address this gap, our development team is organised with a very particular structure. Firstly, there is a Solution Architect who is the visionary for the overall technical solution. The Architect is responsible for ensuring that all extensions, interfaces and reports work together.

Each business area then has its own technical expert. The technical expert will have many years of experience in his own knowledge domain and writes the more complex technical designs as well as being responsible for delivering the vision to the developers.

The technical expert is also responsible for mentoring the offshore developers who report to him (or her). We believe it is important to stress that the relationship here is based on mentoring rather than simply managing. We consider that developers have enough knowledge to code, but that they need a mentor to show them how to approach it in the most effective way.

Many large scale projects hope to reduce the development cycle by combining multiple design documents into a single one, called an MD200. In fact, this can not only delay code delivery but also hinder the resolution of any design flaws and solution interaction. Instead, we make a clear distinction between the functional and technical design documents.

We invest significant amounts of time and money in the technical design documents. These documents contain a full set of UML diagrams to describe flows within the solution and the inter solution dependencies, as well as a complete set of pseudo logic, queries, error handling etc. By the time the technical design is accepted by the technical lead or solution architect, it will be of a quality where a competent developer can write effective code both quickly and accurately.

By using this method and structure, we can be confident in the high quality of the delivered code from your offshore development centre or partner.