Configuring Global Configurations Compatibility

Given the complexity of some products, some applications have implemented what is called Configuration Management. When enabled, this feature allows to define different versions of a given artifact and group them in components. Let's say a company wants to create a plane, the complexity would suggest us to split the design, and process in general, in components: the cabin, the wings, etc. Now, the design requirements for such plane to fly on America may be different from those in Europe; by having different versions of the same components (and the artifacts on them) engineers could achieve all this work easier: one version for America, one for Europe.

A configuration is, in this context, a version of a component: as many different component versions a team need to work with, as many configurations they need to create. All this is good up to one wonder what configuration on RM application should work with what configuration of QM application? In a collaborative environment, different applications care about different parts of the making process and, in a Configuration-Management-enabled environment, it is important to establish a relationship between configurations (from different applications) that work together, here is where the concept of Global Configuration comes in. A Global Configuration (GC) is a configuration where the artifacts are also configurations... but configurations from different applications (RM, QM, etc) that work together. In other words, the global configuration is the mean to define which local configurations work together.

In Jira, it does not make sense to have different versions of an issue [1], this makes impossible to define a local configuration which could become part of a GC, but OSLC Connect for Jira makes possible to create Collaboration Links to applications (supporting OSLC) that do (DNG and RQM). This is done by making use of the Jira Versions and the fields Affects Version/s and Fix Version/s, whose value can be mapped to a GC through a Collaboration Link type. By having this mapping, and in other words, a Jira issue can be linked to remote versioned artifacts, depending on the GC mapped by the Jira Version set on the Affects Version/s or Fix Version/s field; the actual field used to resolve the GC depends on the Collaboration Link type the user is creating. Having said that, to enable this versioned linking capability you need to care of:

  1. Configuring Link Types to Versioned Fields mappings
  2. Associating a Jira Version with a Global Configuration
  3. Making sure versioned fields are part of the screen to Edit/View the issue

If you don't apply these configurations, Jira users won't be able to create outgoing links to CLM Applications with Configuration Management enabled. By applying them, Jira users will still be able to create outgoing links to CLM Applications with Configuration Management disabled.