Wednesday, July 3, 2013

Efficient integration development?

I have been involved in many integration development projects during my career. Some of them have been successful and efficient, some haven't. What is the magic behind efficient integration developent?

Preparation phase

Open conversation about the goals and the means is crucial. Every involved party must have uniform understanding about goals and functionalities that can be used to achive them. When everyone have clear picture about the challenge, it is much more easier to engage and try to put best effort to achieve it. Motivate project with positive awards.

Patterns and reusability: whenever possible try to identify known solution patterns by which desired fuctionality can be achieved. You should not reinvent a wheel every time, except you have room for innovation in our schedule or known bottleneck in the pattern.

Realistic schedule and resource planning: if you have a complex systems, processes or information objects, do not underestimate time schedules. I have witnessed many cases where decent processes / exchanged information were not known after specification phase but many testing-revising cycles were needed in SIT / UAT environments and estimations and schedule were freezed based on the original specs. This lead to feeling of hurry, extended hours, weekend work etc. which decreased the efficiency and quality of the outputs. One tip from the funding point of view: do not argue too much about time estimations but argue on price if you need to spare or meet some limits.

However set multiple deadlines: it is not a secret that nothing motivates better than deadline.

Specification phase

Spent time to think all the possible scenarios. Rethink. And think again. Produce test cases from and for the systems if possible. Simplify. Consider which party is responsible for the needed functionality and could it be handled at that party instead of the middleware. Innovate and procude material also for the exception cases.

Specify (or reuse) functionality for easy to view and ensure content of the flowing messages before and after conversions etc.  The easier way to check these message contents the more valuable  it will be at the SIT & UAT with complex business processes and structures involved.

 

Implementation phase

Step by step development and testing: implement one functionality / mapping rule  at the time and module test that it works as expected with the realistic testing data received from the specification phase. Do not try to implement and test all at once, because you will not be (or at least I'm not) attentive enough to check huge amount of the things in one shot.

If possible try to avoid personification, let development and testing parties to spread knowledge and work inside their teams. This can pay you back in one day when the only developer / tester get a flu and is not available for awhile.

 

System integration test phase

Arrange testing workshop(s)  where all the parties are in place and technical or logical issues can be debugged and fixed immediately. Run and rerun all the system acceptance test cases through in these workshops with increased logging and debugging levels to collect material and experience that these testing cases are working. Try to play with cases and cause exceptions.

Fix dataflows one by one. Do not run multiple dataflow testing and debugging streams with the same resources  at parallel. Your focus will be disturbed and your resources need time to refocus to different subjects and are not as efficent as they could be. Also arrange enough rooms for testing teams so that other subjects do not distract their focus.

Do not move to UAT too early

There are always extra work when debugging and fixing things on two environment parallel, especially you get extra work from evaluating what is set differently in the systems because they are not working the same etc. It is not unusual that some fixes or settings are forgotten to order to or copy to next testing environment. Another thing that might be issue from efficiency point of view is that in some cases deployments to UAT enviroment can be done only in certain time windows and by decent processes.