The Open Services for Lifecycle (OSLC) steering committee is gathering feedback from the community to help shape the future vision and mission for OSLC. As part of that effort a survey of the community members was conducted and it highlights some interesting results about the needs of this group. You can find the full results of the survey here.
OSLC is an open community that builds standards to solve a vexing problem: How to integrate the specialized software used by different types of software and systems development practitioners so teams and their tools can work together.
For example, it’s wildly inefficient for a software tester to file defect reports in her specialized QA software and then send an email to the development team to tell them about the defect so they can manually enter it into their Agile development management tools. There is no place for this type of carrier pigeon communication in today’s world of short development cycles and continuous delivery.
A note about methodology: The survey was advertised via several OSLC-related communication channels and participants self-selected the survey rather than being a random sample. This means the results represent the opinions of that group and may not necessarily be representative of the opinions of the wider community.
Integration Is Desired for Both Systems and Software
The first category in the chart above is “Software Development Lifecycle (SDLC) Tools/DevOps (e.g. Agile, Testing, Requirements, Continuous Integration, etc.) with over 70% of respondents indicating that this is of interest. Systems Engineering and Product Lifecycle Management were also identified as key areas of integration for the OSLC community. While not specifically asked in this survey, supporting the collaboration between SDLC and the world of Systems and Product Lifecycle Management is a key area where OSLC can be applied.
Traceability Is Key
Nearly 80% of the participants identified “Traceability across tools” as a desired benefit of integrating tools. The second and third most common responses were “Requirements coordination with test planning” and “Developer collaboration with QA.” All three of these top responses require an element of traceability between the artifacts managed by each discipline. This is a need that OSLC’s linked data architecture is particularly well suited to address.
Higher OSLC Adoption Is Needed
Like any standard, the benefits of adopting OSLC increase as more organizations adopt the standard. Before a standard is widely used, early adopters need to invest in supporting it to create the necessary critical mass. There are more than 50 known tools that can support OSLC either natively or through a third-party adapter. However, there is still a need for higher adoption and more native support for OSLC among non-IBM tools. The survey reflects this and highlights the “chicken and egg” dilemma, where higher industry adoption would be the primary motivator for the respondents’ organizations to adopt OSLC. With more than 50 tools already capable of supporting OSLC and more than 10 third-party adapter technologies, there is clearly a strong level of industry momentum. See below for more information on how to participate in the discussion on driving OSLC to the next level of adoption where “adoption” itself is no longer an impediment.
Integration is Needed Across a Broad Range of Tools
The survey identified 55 different tools that respondents might have a need to integrate. Some 41 out of these 55 were selected by multiple people. It’s also interesting to note not only the diversity in products/vendors but also in the types of tools involved. The list includes tools for requirements, Agile development, QA/Testing, source code management, PLM, and Service Desk. Together this indicates a long tail of integration needs across a large set of tools. Again this highlights both the need and the potential benefits of a standardized integration approach.
The OSLC steering committee is always looking for more feedback to help improve integration through open technology. We welcome your comments at open-services.net forums and the OSLC LinkedIn Group. Together, we can stop the insanity of carrier pigeon communication across teams and tools.