It is exciting to see so many integration projects pop up in our offshore global delivery center (China GDC). As we know, most integration projects are very often challenging. Since I have worked as the offshore team lead in a mulit-shore integration project, I would like to share what I learned with you.
First, I’d like to list several problems the team faced in the early phase of the project. – I think they might be typical for many integration projects.
Case 1:
Only one central integration environment was used by both the onshore team and the offshore team. Several environment issues occurred, and it just failed to work. This blocked the whole team, from being able to do any integration testing. Let’s call this case as – single integration environment dependency.
Case 2:
Based on the plan, the team needed to complete an end to end integration by end of the week. Though the team had completed the integration component, and was ready for the end-end testing, we were told that the end system functionality (developed by another team) was not ready yet. The integration was delayed. The team had to switch focus unexpectedly.
Or, the two teams did start the integration testing. But due to lack of unit tests, it turned out to many integration test failures. The two teams had to work together to debug and fix issues one by one. Apparently, this is not a very efficient way to work since it causes waiting.
To summarize, an integration project often involves multiple systems, thus requires for multiple development teams. This results in cross team dependencies. If not managed carefully, the dependencies will become issues.
Case 3:
Usually, each development team only has knowledge about his part in an integration project. A tech lead of the integration team would have limited knowledge about functionalities, interfaces, limitations of the source system or target system. This often leads to vague design if without enough attention.
When an integration team member starts to work on an integration task, he could find out that the integration interface is not clearly defined yet, even the integration solution is vague and has many things to be finalized. He will need to work out design details with his tech lead as well as the end system tech lead. Unfortunately, it is very likely that the end system lead will be overwhelmed at that time. Because so many integration designs and interfaces need to be finalized at the time! Communications go back and forth between the integration team developers, end system developers, tech leads, end users. Deadline approaching, a solution has to come out, implementation is in hurry, and unit testing? No time! Also notice that in this process, the senior guy who originates the design, is in the supporting role. The owner of the integration is the developer. Do you see the problem here?
Case 4:
Many changes occurred during the development work. A lot of effort was spent on dealing with changes due to lack of reusable tests.
– As an integration project, changes could occur in source systems, target systems, integration components, or interfaces. Changes could break working functionality unexpectedly, and cause significant effort on manual testing, debugging, defects fixing, etc.
Does these above sound familiar to you? Or are you experiencing the same things now? I hope not, 🙂
Well, with such a number of uncertainties, a single integration would be hard to estimate. How could we manage an integration project in control? Fortunately, I think we figured out the solutions during the project, and that is what I will share in my next post. 🙂
What are your thoughts on this? Thanks!
Very good summary for the issues. I had experienced similar issues as described below:
1. single integration environment dependency – In my experience, both sides need a SA who have the knowledge and experience to solve the problems. So that we can reduce the idle time when the system is down. But sometime, the environment is owned by client SA, then the only way I have is push, push, and push to have the issue solved as quickly as possible.
2. cross team dependencies – We experienced this a lot in current project. While since the other teams are not in our control or even out of Perficient control, this is hard to solve. We should do whatever may help to avoid or reduce the impact. Cross team planning to identify the dates, make sure every team has targeted dates. Collaboration on design to make sure the interfaces are defined clearly, and test cases are defined for verification. Early notice for any possible delay and change to avoid the last minute issue. Periodical sync-up meeting to state the progress. All easy to say but hard to do.
3. vague design – Interface design will be very important and should be reviewed by all the teams to reach an agreement. Deisnged boundaries should be clear to each team. Close communication is also very important during the implementation.
4. Changes – Changes are everywhere, so test driven development is the way to help with that. To have the test cases clearly defined and executed after code is finished/changed will help to eliminate most of the code level problems (Continuous Integration). Leveraging testing tools will help to reduce the effort of this.
Looking forward to your experience.
Great to see your good practices on integration project. I guess I might not need to post the 2nd part, 🙂 They are exactly the key points.
Pingback: Manage an integration project in control (Part 2 – Suggestions / Discussion) - Multi Shoring - A Perficient Blog