.NET offshore

For me the collaboration with Itude and the customer Mediq, started in November 2007. Because of obligations elsewhere I unfortunately could not participate in the kick-off in Chennai, India. As a result I really was thrown in at the deep end during first day at work. The project had two preconditions: .NET and SQL Server 2005. Because of my certification, technically there were difficulties. The challenge was the problem domain; the care market uses technical jargon extensively and knows many complex procedures. Through intensive contact at the customer’s site, I could fill this gap. For me working as an ICT professionals does not only mean buttons and valves. In the end I want to help people or to improve something; to solve a concrete problem or to increase the efficiency of a process. I started the collaboration with the offshore team by having daily contact via phone and MSN. We also had a conference call once or twice per week for the entire team. My role in the project is the designing and preserving the software- en system architecture. This comes down to the communication with the different departments and the contact persons of the customer, in order to be able to subsequently translate their needs into technique. The making of underlying choices is fun and instructive. The time we save in the Netherlands by outsourcing the implementation, we spend in contact with customer. By the way, the communication with India now runs via HD videoconferencing. The first pleasant surprise in the collaboration with our partner in India, was for me the fixed team structure. For a project such as this one, the available domain knowledge is crucial for working efficiently. Not only was the entire team very knowledgeable of all functionality, they also succeeded in making the (sometimes literal) translation smoothly. The product we developed communicates with chain partners via a number of web services. Because of the fluctuating amount of data to be exchanged and the way of addressing this data, this proved not be the most efficient way. Soon it became clear that the completion time of the different batch processes became longer than the actual period. This was not caused by a shortage of, in practice hardly used, system sources. A serial communication pattern made insufficient use of the available resources on both sides. The overhead of all XML and embedded encoded attachments had to be dealt with too. The solution appeared to be obvious, because of a prior choice of architecture. Because of our Java background, we had a preference for Quartz as task planning component. This could easily be expanded with multiprocessor support. In the end a large part of the functionality has been built on top of this implementation. This also enabled the much-needed upgrading; in general the messages may be divided round-robin between servers. Because individual declarations run through one workflow, there not much need for data synchronisation or exchange of state. In June 2009 the Itude project team went to India for two weeks for transfer of knowledge and hands-on optimizations. These were two very pleasant and productive weeks for the entire team. Robert Meijer