Since its inception, Tasktop has been involved with Open Service for Lifecycle Collaboration (OSLC). We co-authored the original specification with IBM and continue to work on the OSLC core technical committee. OSLC provides a set of open standards for connecting lifecycle tools to enable cross team traceability and collaboration. Based on the W3C linked data specification, OSLC enables links to be established across tools, repositories and projects. Those links include semantic information that allows the consuming tool to access not only the data, but also what that data means.
The objective of OSLC is to provide a set of standards that allow all lifecycle tools to connect information in real-time. Imagine a requirement linked to a test case where, in the requirements tool, the test information was accessed and presented to the user without duplicating the test information in the requirements tool. These external links are not just links to HTML pages, but via the specifications provided by the OSLC standard, they also enable the requirements tool to receive certain information from the testing tool. This enables the requirements management tool to do something with this data, such as provide the data in a rich hover for the user, or programmatically update a status field in the requirements tool.
OSLC, however, has been very slow to take off. Vendors are skeptical about the motivation behind OSLC–viewing it as an IBM driven standard. Without strong vendor support, customers don’t see the value. Without customers driving adoption, vendors will not support its adoption. This creates a textbook chicken and egg problem. No motivation to adopt by the vendors, and because of limited adoption by the vendors, no customers asking for it. Complicating the vendor adoption problem further is the fact that customers are not actively looking for a cool architecture for linking data. They simply need to find ways to solve immediate integration problems. They need a lifecycle integration strategy, and OSLC is not an integration strategy. A lifecycle integration strategy is a combination of decisions around workflow, with reviews and discussions about things like how reports are created and what tools do to support traceability with respect to compliance and governance. OSLC standards provide a set of technical capabilities that support aspects of the strategy, but they are not a complete strategy. This fact is also highlighted in the work of the EU Crystal project –a project focused on solving lifecycle integration problems in the area of systems engineering.
By partnering with our customers, Tasktop is able to see OSLC in the context of the integration needs of diverse organizations. This real-world view clarifies the ways that OSLC and linking fit into a broader strategy.
A top down approach
For any strategy to be successful, you need to begin with the needs of your users. Integration is a huge and complicated subject. Each customer organization has its own set of scenarios. Requirements may include:
- Flowing data: When a ticket’s state in tool X becomes ‘defect’ create a defect in tool Z.
- Reporting: Create a report that includes data from discipline A, B for projects Q and R across tools Z and X.
- Traceability: Link a requirement in tool X to a series of tests in tool Z.
- Collaboration: When comments raised about artifact B appear in tool X and Z, allow users of those tools to respond and collaborate in the context of that artifact in the tools they use.
Of course, many integration scenarios are a combination of these requirements. For example, customers may combine flow and collaboration, or reporting and traceability. OSLC can provide support for all of these different types of requirements, but the reality of many tools, coupled with the detailed requirements for each type of need, make OSLC the natural choice for enabling traceability. Traceability is all about linking artifacts – OSLC extends that to enable tools to link a semantically rich connection. And linking is important to any lifecycle integration strategy to support traceability, and help define and structure the flow of information. In fact, since the release of OSLC, Tasktop has been on a journey to better understand the relationships inherent in any lifecycle. This understanding has been the driver behind adding capabilities to Tasktop Sync.
Tasktop and Linking
In April 2014, Tasktop released artifact relationship management (ARM). The objective for ARM was to enable customers to express relationships across tools–even when relationship models in each tool were different. For example, RRC and HP ALM describe the relationship between a requirement and a test in very different ways. A customer who has requirements in RRC and tests in HP ALM requires the relationships to be described in a way that both tools understand and can act on (important not to lose the relationship between tools). Another interesting dimension of the ability to integrate links is how those links are stored. ARM enables users to store relationships differently–depending on whether the tool supports that artifact type or not. For example, the RRC data model does not support the test plan artifact. Doors NG is a requirements tool, and would expect a customer to use Rational Quality Manager (RQM) or another testing tool to manage test artifacts. HP ALM has a model representation for requirements and would expect the requirement to be stored within that tool. ARM enables users to express these different integration rules as internal associations (when the tool has the model representation) and external associations (when the tool does not). This means that sometimes internal links (links to artifacts within the tool) and external links (links to the artifact in another tool) make sense depending on the tool and what the customer is trying to achieve. Maybe it is better to provide an external link to a master artifact in another tool rather than synchronizing that artifact into the tool and using an internal link.
So what about OSLC?
Now that we have added context in relation to the customer needs for OSLC and how ARM supports linking, let’s circle back to how Tasktop supports OSLC. We introduced OSLC support in 2011 with our 2.0 product release. This functionality was driven by our commitment to supporting the standard, and to helping a customer who was experimenting with linking information. At that time, we introduced functionality that allowed customers to describe their mapping to a particular project and tool and make the mapping accessible via an OSLC provider. Tasktop Sync acts as an OSLC provider, allowing customers to create mappings for their OSLC interfaces without the need to write complex REST API’s. Tasktop also enables non-developers to create OSLC interfaces that can be consumed by any OSLC compliant tool (when this functionality was first added, only IBM Rational CLM tools were compliant).
Enabling OSLC external links
It is no surprise that Tasktop treats OSLC like any external link, enabling the link to be written in an OSLC form. Unlike many implementations of OSLC (where the link is added by the user of one tool), Tasktop Sync creates the links automatically, based on rules. By combining the external OSLC link with the OSLC provider that Tasktop Sync provides for non-OSLC tools, users can create an OSLC link with ARM, which can then be programmatically executed by the user. One good example of this is DOORS NG to HP ALM. BAs within DOORS NG create requirements. A subset of the requirements information is synced to HP ALM allowing the testers to create the associated test cases. A traditional HP web link is provided to the HP ALM requirements, allowing the tester to see the requirement in RRC. Once the test cases are created within HP ALM, an OSLC link is provided back to RRC allowing RRC to execute traceability reporting. Also, because there is a model element within HP ALM that represents the requirement, it is possible to take advantage of HP reports and also add metadata to the model element that is synced back to DOORs NG. This metadata can include status or rollup test success that can be included in reports in DOORS NG or HP QC. This combination of OSLC and syncing provides tool admins with the flexibility to use the approach that best supports their needs. For example, it might benefit the BA and testers to include in-context collaboration. By having an artifact in HP ALM, comments can be written and then synchronized to DOORs NG, eliminating the need to use email to discuss a requirement. Synchronization of a requirement between RRC and HP ALM is programmatic– it only happens when key data is entered or the state of the artifact reaches a certain point. This allows process management to be undertaken with only certain requirements entering the tester’s backlog to be worked on. This process automation helps manage the volume of work and supports process models such as KANBAN or Scrum. It also allows organizations to set Work In Progress (WIP) limits, allowing the introduction of Lean approaches to the management of work.
It not about linking or synchronization it is about flexibility and value
OSLC, like any standard, has its zealots–people who think replication is evil and OSLC is the Holy Grail of integration. But the reality is that integration is a more complex problem than any one protocol or approach can solve. I hope I have demonstrated that our approach combines OSLC with other integration models allowing for a solution that meets customer needs. Customers have particular needs and look to integration to help them solve process, team-work, reporting and/or compliance governance problems. Tasktop is committed to providing the infrastructure that customers need to solve problems and achieve software delivery success. OSLC is a key protocol, and as its adoption grows and usage patterns emerge, we will continue to extend our support for the protocol. It is clear from our support for OSLC that there is the need for infrastructure that connects the protocol and associated interfaces with the reality of the legacy tools and schemas. OSLC will continue to be a fundamental part of our infrastructure solution and Tasktop is committed to help drive the standard to be more inclusive of the realities of customer tool situations. I write this as both the Chief Product Officer of Tasktop AND a member of the OSLC steering group.
Dave West Tasktop CPO and OSLC steering group member
