Managing Integration Dependencies

  • Josh Hooks

December 19, 2013

A frequent question that arises when planning any large IT project:

“How do I manage the dependencies between all of this integration work going on at the same time?”

Anyone would be hard-pressed to find a question more likely to cause almost any roomful of IT program managers and architects to hang their heads in despair and frustration. Everyone will quickly volunteer their own nightmarish stories about projects going off the rails thanks to a lack of good answers to this question.

A follow-up question that we hear all the time in the Guidewire Professional Services group:

“I want to use an agile process for my Guidewire InsuranceSuite implementation, but many other teams who will deliver the other integration components follow a strictly waterfall approach. How do I reconcile the two approaches and still be successful?”

Since my blog space is limited, I cannot give you a step-by-step guide to making it all work. But I can give you a set of principles that our most successful customers tend to rely on in practice:

  • End-to-end integration testing is the most powerful way to measure progress. In practice this means starting full-length tests in early sprints, even if most of the functionality on both sides of the integration needs to be mocked out. As functionality is added, either sprint-by-sprint or at pre-arranged milestones, the tests can be switched to use the real thing.

  • Use both formal and informal communication to keep all teams and suppliers honest. Weekly team lead meetings are helpful to catch big items, but informal relationships are invaluable for catching semantic differences and focusing on the goal of combined success. Do both teams know each other? Are they enabled to work one-on-one together on issues?

  • Plan to have a backup plan. At the beginning of a project, almost everything seems to be a high priority on the critical path. When things get difficult later it can be amazing what other options are available as alternatives. Instead of waiting until crunch time to understand these, carve out some time to talk about them up front. Do you really need that other system on Day One, or is there a workaround to give you some breathing room for a few weeks or months?

Understanding and applying these principles will go a long way to putting smiles back on the faces of those working on a core system implementation.