Why Integration requires a combination of linking and syncing

Since its inception, Tasktop has been involved with Open Service for Lifecycle Collaboration (OSLC).  So much so that 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 cross tool, repository and projects. Those links include semantic information that allows the consuming tool to access not just the data but 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 requirement tool the test information was accessed and presented to the requirements tool user without having to duplicate 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. For example provide a rich hover or update a status field. By providing specifications, tools can present information consistently across the lifecycle. Or that is the objective of OSLC, standard API and information structures for all lifecycle tools.

OSLC has however been very slow to take off. Vendors have been skeptical of the motivations of OSLC, seeing it as an IBM driven standard. And without strong vendor support customers do not see the value, and without customers driving adoption vendors will not support its adoption. Thus a chicken and egg problem. No motivation to adopt by the vendors and because of limited adoption by the vendors, no customers asking for it. But adding to the political / vendor adoption problem is something more fundamental. Customers are not looking for a cool architecture for linking data, but instead need ways to solve their 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, where reviews and discussions are undertaken, how reports are created and what tools do to support traceability with respect to compliance and governance. OSLC is a key part of the strategy providing a set of technical capabilities that can support aspects of the strategy, but not the complete strategy. The lack of OSLC being an integration strategy is also highlighted in the work of the EU Crystal project who are focused on solving lifecycle integration problems in the area of systems engineering. To provide more content around solving particular problems Crystal adding materials on top of OSLC, layers that augment OSLC to support real systems engineering use cases. They are also adding other types of integration adding to linking with synchronization and streaming.

By partnering with our customers Tasktop has looked at OSLC in the context of their integration needs and have found how OSLC and in particular linking fits into a broader strategy. Let’s first look at their needs in a bit more detail.

A top down approach

For any strategy to be successful, the place to begin is the top, with the needs of the customers. Integration is a huge subject and each customer has their own set of scenarios. Customer requirements may include;

• Flowing data. When a tickets state in tool X becomes ‘defect’ create a defect in tool Z.
• Create a report that includes data from discipline A, B for projects Q and R across tools Z and X.
• Link a requirement in tool X to a series of tests in tool Z.
• Comments raised on artifact B appear in tool X and Z allowing 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 as customers combine, for example flow and collaboration or reporting and traceability. OSLC can provide support for all of these different types of requirements. However, 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 not only supporting traceability, but also helps 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, which led us to add capabilities to Tasktop Sync to better expose those models.

Tasktop and Linking

In April 2014 Tasktop released artifact relationship management (ARM). The objective for ARM was to enable customers to express relationships, cross tool even if those relationship models in each tool are different. For example how RRC and HP ALM describe the relationship between a requirement and a test is very different, but a customer who has their requirements in RRC and their tests in HP ALM requires the relationships to be described in a way that both tools understand and can act on. You do not want the relationship to be lost between tools. Another interesting dimension of the ability to integrate links is how those links are stored. ARM will enable users to store relationships differently depending on if 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 the test artifacts. However, HP ALM does have a model representation for Requirements and thus would expect the requirement to be stored within that tool. ARM enables users to express these different integration rules as, internal (when the tool has the model representation) and external (when the tool does not) associations. Both internal and external links make sense depending on the tool, and the strategy being adopted by the customer.

So what about OSLC?

So, now we have put some customer context around the customer needs for OSLC, and how ARM supports linking we need to circle back to how Tasktop supports OSLC. Tasktop introduced OSLC support in 2011, with the 2.0 release. This functionality was driven by both a commitment on our part to support the standard, and a customer who was experimenting with linking information.  We introduced functionality that allows customers to describe their mapping to a particular project and tool, and for that mapping to accessible via an OSLC provider. Tasktop Sync acts as an OSLC provider. This enables customers to create mappings for their OSLC interface without having to write complex REST API’s. Tasktop enables non developers to create OSLC interfaces which can be consumed by any OSLC compliant tool – which at this time of adding this functionality was only the CLM tools from IBM Rational.

Enabling OSLC external links

It is of no surprise that Tasktop treats OSLC as any external link, enabling the link to be written in an OSLC form. But unlike many implementations of OSLC where the link is added by the user of one tool Tasktop Sync creates those links automatically based on rules.  By combining the external OSLC link with the OSLC provider that Tasktop Sync provides for non OSLC tools, customers then can create an OSLC link with ARM which then can be programmatically executed by the consumer. Perhaps the best example of this is with DOORS NG to HP ALM. BA’s within DOORS NG create requirements. A subset the requirements information is sync’d 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 representing the requirement it is possible to take advantage of HP reports and also add meta-data to the model element that is sync’d back to DOORs NG. This meta-data can include status or roll up test success which can be included in reports in either DOORS NG or HP QC. This combination of OSLC and syncing provides the tools admin with flexibility, using the right approach to support their needs. For example it might be a benefit to the BA and testers to include in context collaboration. By having an artifact within HP ALM, comments can be written and then synchronized to DOORs NG, thus removing the need to use email to discuss a requirement. Synchronization of a requirement between RRC and HP ALM is programmatic, meaning that it only happens when some 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 can help manage the volume of work and support process models such as KANBAN or Scrum. It also allows organizations to set Work In Progress (WIP) limits in their process 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 that OSLC is the Holy Grail for integration. But the reality is that integration is a more complex problem than any one protocol or approach can support.  I hope I have demonstrated that our approach combines OSLC with other integration models allowing for a solution that solves customer’s needs. Customers all have particular needs and are looking to integration to help them solve not an integration problem, but a process, team work, reporting or compliance governance problem. Tasktop is committed to providing the infrastructure that allows customers to solve problems and is only zealous about customer 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’s tool situations.  And 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.