This is part 2 of a 3-part series of blog posts about Linked Lifecycle Data (read part 1).

What is Linked Lifecycle Data?

Linked Lifecycle Data is simply the application of Linked Data principles to data created and maintained during the lifecycle of systems and software development projects.

The traditional approach to data integration

Traditionally, much of the data that we create and manage during the lifecycle of the systems and software projects that we are involved in is not open. Historically this data has only been available to users of the tool that manages that data. In such closed environments, we’re prevented from answering complex questions that rely on our understanding the relationship between data managed by different tools. Furthermore, the tools in such closed environments have no common understanding of the types of data and relationships that they are managing.

This problem is not new and has been attempted to be addressed in several different ways in the past. Using a single repository to manage all the data is unrealistic as it implies a single vendor tie-in and prevents adoption of best of breed solutions and integration of data that you may have in existing repositories. Point-to-point integrations between multiple tools are brittle and prone to breaking when tool versions are updated. Adoption of universal metadata standards has been shown to be unsuccessful due to conflicting priorities and motivations of multiple vendors, coupled with the fact that it provides no flexibility for individual teams to customize.

Is there a better way?

Adopting a loosely coupled approach to integration based on Linked Data principles in systems and software development allows us to truly make the most of the data that’s being created, without the down sides of other approaches that have inevitably failed in the past. The foundation of Linked Data and what makes it work are the URIs. The URIs ensure that the data is identifiable even outside its original context.

Despite the more limited scope of the data (typically managed within a few tools on a private network), we’re still able to derive huge benefits from applying Linked Data principles to it. By ‘opening’ the data managed by all of these tools we can create a well-defined system of tools that allows users working within any of the tools in that system to answer complex questions about the projects that they are working on that rely on the union of data held in disparate repositories.

A Linked Lifecycle Data example

Here is a Linked Data representation of some development lifecycle data. This set of triples (again in Turtle) shows a linked requirement, test case, and work item.

@prefix dcterms:<http://purl.org/dc/terms/> .
@prefix oslc_cm:<http://open-services.net/ns/cm#> .
@prefix oslc_qm:<http://open-services.net/ns/qm#> .

<https://rqmtest.ibm.com:9443/rm/requirement.1> dcterms:title "Requirement 1" .

<https://rqmtest.ibm.com:9443/qm/testcase.1>
dcterms:title "Test case 1";
dcterms:description "The quick fox jumps over ... ";
oslc_qm:validatesRequirement <https://rqmtest.ibm.com:9443/rm/requirement.1> .

<https://rqmtest.ibm.com:9443/cm/defect:645>
dcterms:title "Defect XYZ";
oslc_cm:testedByTestCase <https://rqmtest.ibm.com:9443/qm/testcase.1>;
oslc_cm:implementsRequirement <https://rqmtest.ibm.com:9443/rm/requirement.1> .

Continue to Part 3 of this blog series, where we discuss Lifecycle Query and how Linked Lifecycle Data can provide benefits in Systems and Software Engineering environments.

Benjamin Williams
Senior Product Manager, Rational Systems Platform
bwilliams@uk.ibm.com