Commercial software applications often tend to be quite loose and non-binding of any conventional semantics when it comes to implementation of their metamodels. This not only impairs their usability but also has significant impact to their ability to integrate with other applications and systems in an environment.
A case in point -- Atlassian's Jira issue management application -- which has become quite popular with organizations of all sizes as well as a number of open source communities. With over 10,000 customers for its products, it is no wonder that we (zAgile) have been taking a closer look at the Atlassian application suite with respect to integrating them into our semantic framework for our customers.
One of the most curious aspects of Jira that has often perplexed potential adopters is its metamodel. We see people often confused with some of its key concepts or use them arbitrarily thus potentially contributing to a different set of usability problems.
Most notably in this context is the Jira 'Project'. This defies any coherence with the common or conventional notions of a Project. For starters, people tend to associate projects with a begin and end date. Not so in Jira. Projects go on forever with interim deliveries packaged as releases. So what is a Jira project and how do you plan one?
Then there is Component. It seemed intuitive at first since semantics of the word 'component' are also not too controversial--that is until you begin to see how people have applied it in practice in Jira.
To understand the usages of some of these fields, you can look at Atlassian's JIRA site. Another popular Jira site for us has been JBoss.
In both usage models, the concept of Project more closely resembles a software product or component (example -- Jboss Enterprise Platform, JEMS, Jboss Shotoku, Bamboo, Clover, JIRA, etc). There is no hierarchy or crossover relationship between software components so the issues or tasks within each have to be fairly isolated from those belonging to another Project. Of course, there are Project Categories (example: Atlassian Products, JIRA Plugins, etc) -- to help organize the Projects. But how do those fit into our mental model of Projects?
Similarly, I have seen examples of Components such as QA, Performance, Test Suite and Documentation. Its tough to figure out the definition (or semantics) of Component from such usage.
And finally, if we are going to be arbitrary in terms of how we use these fields, then how do we integrate them with similar concepts in other tools? Is a Jira Project the same as an MS Project instance? Are all values in Component representing software components?
This emphasizes the value of common and shared semantics in applications that would facilitate both usability and potentially integration. While Jira has a lot of third-party support to make it functionally rich, a lot of people are still spending significant amount of effort towards integrating it with other applications and processes within their environment. And many of them are struggling with the lack of consistent and coherent semantics.
-Sanjiva, Orinda, October '08
Comments