When evaluating tools like JIRA, HP ALM, or IBM Rational, it’s important evaluate project needs vs product capabilities. Obviously the costs of getting started with JIRA are much lower than some alternatives. But sometimes, being penny-wise can result in being pound-foolish.
For a simple “MVC” type application with a limited set of components, it’s likely JIRA’s features will be adequate. Or project needs can be met with some minor customizations and/or plugins.
However, when managing ongoing development of systems which contain many levels of hierarchical components, the JIRA limitations may present significant obstacles. For many years, there have been open feature requests regarding support for hierarchies. As of March 4, 2014, JIRA’s response is that it will be another 12 months before they “fit this into their roadmap”.
For large distributed systems, with complex dependencies, this presents a significant challenge.
While setting up a new JIRA/Atlassian environment for a solution comprised of 8 major applications, I’ve found that it is not possible to create a hierarchy of subcomponents. Nor is it possible to establish versioning for those subcomponents. Instead, the JIRA data model and workflows are designed for all components of a project to exist as a flat list. And for all components to be on the same version / release cycle.
For our solution, many of the major applications start with a commercial product, incorporate multiple modules, integrate an SDK, integrate 3rd Party plugins, and finish with custom coding of multiple subcomponents. The design pattern is to establish interface boundaries, decouple the components, and enable components to be updated independently (some people call this SOA).
Now I’m am getting a clearer picture of when it is time to consider alternatives such as HP ALM or IBM Rational. In the past, I’ve encountered several very successful JIRA implementations. And I’ve encountered a number of failures.
Comparing my current experience of setting up a new “systems development” project in JIRA with those past experiences, now I understand the tipping point was a matter of component complexity. JIRA’s architecture needs to be changed such that components can be containers for other objects, and can be versioned independently. There are elegant/simple ways to introduce a data model which supports this, it will likely require them to refactor most (if not all) of their application stack. Given their success with smaller projects, it’s easy to understand their business decision to defer these feature requests.
JIRA continues to recommended workarounds, and several 3rd party plugins attempt to address the gap. Unfortunately, each of these workarounds are dependent upon the products internal data model and workflows. JIRA themselves have discontinued development of features which support one of their suggested workarounds. And some 3rd Party plugins have stopped development, most likely due to difficulties staying in sync with internal JIRA dependencies.
It can take six months to two years to get an HP ALM or IBM Rational solution running smoothly, and there are ongoing costs of operational support and training new developers. However, there are use cases which justify those higher costs of doing business.
It’s unfortunate my current project will have to make do with creative workarounds. But it has provided me an opportunity to better understand how these tools compare, and where the boundaries are for considering one versus the other.