Welcome!

@DevOpsSummit Authors: Liz McMillan, Elizabeth White, David Linthicum, Zakia Bouachraoui, Yeshim Deniz

Related Topics: @DevOpsSummit, Open Source Cloud, @CloudExpo

@DevOpsSummit: Blog Post

Debunking the OSLC Link-Only Myth | @DevOpsSummit #API #Agile #DevOps

Open Services for Lifecycle Collaboration is an open community for creating specifications for integrating lifecycle activities

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.

More Stories By Wesley Coelho

Wesley Coelho is the Senior Director of Business Development at Tasktop Technologies. At Tasktop, he has taken a leading role in creating an extensive network of ALM integration partners including ten OEM distribution partnerships with companies such as IBM, HP, and CA Technologies.

Prior to Tasktop, Wesley led a software development team pioneering a new generation of eCommerce technology at Elastic Path Software. Wesley holds an undergraduate degree in Commerce from the University of Victoria and an M.Sc. in Computer Science from the University of British Columbia (Canada).

More Stories By Rainer Ersch

Rainer Ersch is a Senior Research Scientist with more than 33 years industry experience. He has worked as a director of SW Development Tools Enterpise Communications as well as serving as a consultant and coach for System and Software Development Environments. He has been active with the OSLC community as a member of the Steering Committee for over two years and as the workgroup lead of the ALM-PLM Interoperability Workgroup.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@DevOpsSummit Stories
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO Silicon Valley 2019 will cover all of these tools, with the most comprehensive program and with 222 rockstar speakers throughout our industry presenting 22 Keynotes and General Sessions, 250 Breakout Sessions along 10 Tracks, as well as our signature Power Panels. Our Expo Floor will bring together the leading global 200 companies throughout the world of Cloud Computing, DevOps, IoT, Smart Cities, FinTech, Digital Transformation, and all they entail. As your enterprise creates a vision and strategy that enables you to create your own unique, long-term success, learning about all the technologies involved is essential. Companies today not only form multi-cloud and hybrid cloud architectures, but create them with built-in cognitive capabilities.
In today's always-on world, customer expectations have changed. Competitive differentiation is delivered through rapid software innovations, the ability to respond to issues quickly and by releasing high-quality code with minimal interruptions. DevOps isn't some far off goal; it's methodologies and practices are a response to this demand. The demand to go faster. The demand for more uptime. The demand to innovate. In this keynote, we will cover the Nutanix Developer Stack. Built from the foundation of software-defined infrastructure, Nutanix has rapidly expanded into full application lifecycle management across any infrastructure or cloud .Join us as we delve into how the Nutanix Developer Stack makes it easy to build hybrid cloud applications by weaving DBaaS, micro segmentation, event driven lifecycle operations, and both financial and cloud governance together into a single unified st...
For far too long technology teams have lived in siloes. Not only physical siloes, but cultural siloes pushed by competing objectives. This includes informational siloes where business users require one set of data and tech teams require different data. DevOps intends to bridge these gaps to make tech driven operations more aligned and efficient.
Daniel Jones is CTO of EngineerBetter, helping enterprises deliver value faster. Previously he was an IT consultant, indie video games developer, head of web development in the finance sector, and an award-winning martial artist. Continuous Delivery makes it possible to exploit findings of cognitive psychology and neuroscience to increase the productivity and happiness of our teams.
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.