Situations where JIRA doesn’t meet the needs of a project (JRA-846).

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”.

Jira JRA-846 Support for subcomponents

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.

2 thoughts on “Situations where JIRA doesn’t meet the needs of a project (JRA-846).

  1. Valid points. The problem I have with the more complex products by companies like HP and IBM are the excruciating costs. In addition to the acquisition costs the annual cost to renew support is a real killer.

    I’m on board for the type of product you describe (ALM, Rational) except that so many of the companies that I know of that have implemented this type of system have been unable to manage the configuration/process and usage changes to make these tools really reach their potential without a large amount of contract hours from the manufacturer to configure and train users.

    The workarounds with open source projects may not be very good, and in some cases non-existent. Some of the advanced features are really immature. (For example Release Management feature of JIRA from what I’ve seen is limited). Perhaps breaking down the management to separate projects would be a workaround (not ideal of course) but there is some flexibility there. You could also go write yourself some JIRA plugins – in your spare time…

    It almost seems that a third class of products would be desirable, something that combines the configurational simplicity and cost of JIRA with the flexibility re: software projects and their management as in ALM.

    Fantastical – in the traditional sense.


    1. Hey Gretchen,
      Completely agree about the costs. There’s also the modular pricing. Two recent clients went into projects with, “we’ll do it all in HP ALM”. Then realized they only had a limited set of modules and it would take months (or longer) to procure the missing modules.
      JIRA’s release management concept is still something of a head scratcher for me. Customer and ISV talk about Agile, but this current project was laid out as waterfall. In JIRA, we’ve already set up a series of quarterly .x releases. But now I’ve convinced the team to do smaller and more frequent code drops (weekly builds into QA), and it is less than obvious how to deconstruct a release into a series of builds. [Yeah, I’m still early into my learning curve with JIRA.]
      I am still considering creating multiple projects to get better visibility into the components, but it seems like an artificial workaround. In theory each component is loosely coupled, but in reality they are all extremely interdependent. Sound like anyone we know? LOL.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s