About Software Integration Projects

Our small software team is soon finishing an integration project where a new web-based system has been developed and integrated to work with the registry and sales management systems in the client's old environment. Prior to this project, I was dealing mostly with web and enterprise system projects, but I must admit that this past experience did not help me as much as I thought. Now as the project is about to be ready, some conclusions can be drawn up to help in the planning of similar projects in the future.

Firstly, integration projects are very demanding. The project usually involves the usage of several systems and experience on enterprise systems and the know-how in multitier architecture is a benefit. I was able to apply the previous knowledge from older enterprise system projects built on IBM WebSphere, JBoss and Tomcat.

Secondly, client's old systems and their interfaces must be easily accessible from the new project. The client has to have people who know well the behaviour of their own systems and those systems should also be well documented. It is hard to start designing the new system without thorough understanding of how to connect those older services and how they behave. In our recent case, some of the client's own software people had changed the employer and we had to proceed with a very small amount of documentation through trial and error methods.

Thirdly, software fellows with prior experience in older technologies might be needed when working with legacy systems. I remember a day at Kamppi-office when one of the senior programmers felt that he should move to Russia with his family just because nobody wants Perl/Unix dinosaurs anymore. The good news for him is, in our current integration project the mostly used language was Perl, that I was mainly interested in 1995-1997 before the switch to Servlets and JSP on the server-side programming. Thus, a developer group, consisting only of talented Java people, would definitely be an expensive solution for an integration project.

Lastly, in our project, we have another party working for the User Interface part when our team deals more with the back-end of the project. Occasionally, it has been a challenge to combine our efforts and we have sat in the meeting rooms for long, long debugging sessions. However, the situation has improved by sharing the logging information in real-time and by making sure that everybody understands clearly the most important interfaces. Well made interface document on the wall removes uncertainty and keeps the big picture in everybody's mind making the project prioritizing and scheduling much easier task.

With these points in mind, it should be a bit easier to allocate time and resources for an integration project in the future. Now just towards last debuggings and the zero hour in our project.

BR,

/markus