Most large organizations require dozens and sometimes hundreds of specialized software tools to manage the lifecycle of the physical products or software applications they create. It isn't hard to imagine the monumental waste these organizations incur in attempting to manually coordinate the efforts of the teams that use these many disparate tools to create a single product. Open Services for Lifecycle Collaboration (OSLC) is an open community for creating specifications for integrating lifecycle activities across tools to address this problem. Now imagine how much more happy and productive an organization would be if all those tools could integrate via standard interfaces. In broad strokes, this is the goal of the OSLC community.

The technical foundation for OSLC is based on the W3C Linked Data method of publishing and accessing information and inspired by how the World Wide Web works. This "Linked Data" foundation is often misinterpreted to mean that data should only be linked across systems and never replicated or modified. The reality is that OSLC fully supports Create, Read, Update and Delete (CRUD) operations on lifecycle artifacts such as stories, defects and tests in a way that enables them to be integrated across systems through replication. Those artifacts, however, should of course be linked with one another across systems using OSLC links for navigation and traceability across systems. See the OSLC Primer for more detail.

While replication is fully supported by the technical underpinnings of OSLC, it is a widely held best practice within the community that data should only be replicated sparingly and only when necessary. Replicating data is inherently complicated and can lead to data inconsistencies if not done properly with a sophisticated toolset that must be correctly configured. However, the "C" in OSLC stands for "Collaboration" and the point of OSLC is to facilitate collaboration in the ways that create the most business value rather than to dictate a specific integration philosophy. And this means that replicating data with proxy object representations is OK when necessary to achieve the business outcome. In this case, a "proxy object" means a representation of a lifecycle artifact stored in another repository. Proxy objects should only contain values needed for local context and have an OSLC reference to the original object to apply services (e.g., CRUD).

Consider, for example, a software delivery team where the developers are using an Agile planning tool for software project management and the testers on the QA team have selected a specialized quality management tool to manage their work. The developers and testers require integration so that testers know what features and stories to test, while developers know which identified defects must be fixed.

To satisfy this integration need, Stories in the Agile planning tool can be represented as proxy objects (Requirements) within the quality management tool. Links are used to connect these two artifacts across systems for traceability. This allows the tester using the quality management tool to read the requirement and create the corresponding test cases to test it. Furthermore, the internal link between the requirement and the test case within the quality management tool enables traceability and reporting so the tester can verify that tests have corresponding requirements and vice versa.

Now when the tester inevitably finds a defect in the software, that defect report is filed in the tester's quality management system of choice and linked to the corresponding test case. But this doesn't get the defect fixed. The next step is for a proxy representation of the defect in the quality management tool to be created in the Agile planning tool and linked back to the original defect. This enables the developer to schedule the defect to be corrected in an upcoming Agile sprint.

As this example illustrates, addressing the business need for integration can require a combination of linking and replication techniques. While the information that is replicated should be minimized as much as possible, this approach is fully supported by OSLC. While Linked Data techniques are a crucial part of the solution and a foundation of OSLC, the notion that OSLC is only about links is just a myth.