Decoupling the ALM Tool Stack: A Progression Towards Simple Integrations

Session Type: 
Standard [35 minutes]
Speakers

The trend in modern ALM stacks is moving away from tightly knit integrated stacks towards looser combinations of tools. If you look at the progression of ALM stacks over the past 15 years, you'll notice a few major divisions.

  • In the bad old days, the only fully integrated tool stacks were expensive and complicated. But if you didn't have the budget for the whole line of Rational tools, it was very difficult to quickly integrate your tools from requirements management down to defect tracking.
  • In the mid 2000s the more modern web based tools started to develop effective plugin systems. Now you could write a JIRA plugin to pull in data from DOORS in a few days.
  • The recent explosion of simple web based communication standards has made it incredibly easy to stitch together a disparate set of tools in a few hours, as long as you don't need a deep integration.

If you're a tool vendor like Perforce or a team lead trying to make your tools work together, you're now faced with a choice: Should you choose a cheap, lightweight integration, or invest in a more capable but more expensive integration? In some ways it's similar to deciding whether to invest an a platform-specific mobile application, or build a standard HTML5 mobile browser application.

I've faced this question from both perspectives and I'll use three examples to illuminate the decision.

  • Working on a small software project, I had to decide between buying a well integrated code hosting and ticketing solution that integrated with Eclipse, or making my free tools (Asana, Bitbucket, and Eclipse) talk to one another. I chose the latter route and had a functional but rough REST-based solution in about 2 hours.
  • Working at Perforce, I often help customers choose between a very simple defect tracking integration that takes about an hour to put together; or investing time in Perforce's more robust Defect Tracking Gateway. The latter offers real benefits, but there's a price to pay in deployment and maintenance complexity.
  • Perforce built a very slick Eclipse plugin and it's one of our most popular integrations. But we're currently designing a new code review and merge request tool, and we're not sure how much IDE integration it needs. For starters we're going to put in RSS feeds to surface the data in Eclipse and Visual Studio, and use simple conventions to let the user trigger code reviews. Should we do more? Do we understand enough about what our users want to do with code review in Eclipse to make the decision yet?

With these examples I'll drill down to the two key questions that a tool vendor or in-house integrator needs to ask:

  • Where do you draw the line in your integration? Do you accept a limited integration that uses standard communication tools (e.g. RSS, REST) but offers a limited workflow?
  • Do you know enough about your ideal workflow in advance to even make the decision? If not, it seems that choosing the lightweight integration route is the best choice.

Schedule info

Status: 
Declined

Audience

Track: 
ALM Connect
Experience level: 
Intermediate

Copyright © 2013 The Eclipse Foundation. All Rights Reserved.