The term OSLC stands for Open Services for Lifecycle Collaboration — an open community that works towards contributing new guidelines and getting rid of the bottlenecks in highly coupled integration setup.
OSLC framework can work cooperatively with various tools belonging to different domains. In short —
OSLC makes life easier — here’s how
Let us consider a scenario where the role of a tester and a developer are involved.
Suppose a QA person working in his/her own tool uses Quality Center and logs Defects into the tool. Now whenever a defect arises, the quality analyst notifies about it to the respective developer via emails. To get the issue fixed, the developer manually enters their own development management tool and starts working on it.
Considering the above scenario — is this the right approach towards cross-team collaboration? Can the teams maintain a legitimate traceability and meet the expected deadline?
This is where OSLC-based integration comes into the picture. In the case of an OSLC-based integration, data synchronization is not required. Here, data can be directly linked between the applications.
Understanding the OSLC functionality
OSLC is often called the ‘write-once-integrate-everywhere’ solution. An OSLC-based integration is accomplished between a consumer application and an external provider application. OSLC provider application helps to make its resource data available to the consumer application via delegated OSLC Interface. This is possible because a consumer application can establish links with the provider application.
About OSLC Consumers and Providers
Let us assume that you have an issue tracking configured in Atlassian Jira and you are entrusted to coordinate this tool with Rational Team Concert (RTC). What would you do then? Think of some code that would connect a Work Item from RTC to Jira?
If you need to establish a link to an issue in Jira with a defect in RTC within RTC, then, in that case, Jira acts like an OSLC Provider that provides data to OSLC ecosystem and RTC acts as a Consumer Based on the scenario, an OSLC Consumer and Provider will vary from tool to tool. The same tool can act as a consumer in one case a provider in another.
Here is an illustration showing the interaction that takes place between the consumer and the provider application.
Image source: https://www.ibm.com
As an OSLC consumer, the application can create or query resources in the provider application as well as keep hold of the links related to those resources. With the help of the links, consumer applications can send requests to the provider application as well as query, update or delete the resources.
Kovair provides OSLC interface
Kovair supports Open Services for Lifecycle Collaboration- OSLC. It helps to integrate native Rational tools like RRC, RTC, RQM with non-OSLC ALM tools such as HP Quality Center, Microsoft TFS, Enterprise Architect, JIRA, Microsoft SharePoint, Salesforce, and others. Here all the non-OSLC tools will act as an OSLC Provider.
Kovair introduced a technology called the OSLC wrapper around its Omnibus integration platform. As a result, all the Omnibus connected tools could be exposed as “OSLC Service Providers.”
A domain data is exposed based on an OSLC-domain specification by Kovair OSLC Provider and it serves OSLC Consumer tools sending queries that are related to creating, updating, and deleting resources with help of REST API. Kovair Omnibus provides a delegated OSLC User Interface (UI). With OSLC Wrapper, Jazz-based Rational tools could be quickly integrated with an extensive variety of ALM tools offered by renowned vendors as well as with a set of legacy tools offered by Kovair. Considering an example, with the help of Omnibus Platform, any artifact of IBM RTC or RRC or RQM can be set up using a live link to connect another artifact of Microsoft TFS, HP Quality Center or to any other Rational tools.
Kovair OSLC Bridges the Gap Between PLM and CLM Users
It is a fact that the work done by the product design engineering team and the software engineering team is completely different. Most of the time these teams work in isolation. Generally speaking, a separate set of tools are used to serve their purpose and hence maintaining traceability between the design artifacts and the development work items become extremely difficult. OSLC together with Omnibus, play a significant role in establishing traceability between PLM and CLM tools.
For example, a product company requires the implementation of an embedded software. It, therefore, requires a feasibility study on Systems Engineering Approach to assure the delivery of best customer value.
The product designing team needs to work in collaboration with software engineers to get the software implemented. The whole system that is subject to change is composed of hardware, firmware, and software elements. Kovair Omnibus together with OSLC helps to connect Windchill PLM to RTC tool.
By utilizing OSLC links, users can link, unlink or edit the artifacts from both the tools. Windchill Change Request and Change Notice can be associated with a new or an existing RTC work item. In the same way, an RTC work item can be linked from a Windchill artifact. There will also be a provision for users to preview and edit an artifact from both the tools.
Kovair Creates Traceability Between Business Analysts and Testers
The benefit can be best explained when we investigate a hypothetical scenario. Let us consider that in this scenario, the business analysts are using a DOORS NG tool while the tester is using an HP ALM tool.
The business analyst submits a requirement using DOORS NG. Consequently, a subset of the requirement is automatically synced into HP ALM, enabling the tester to create related test cases. An RDNG Requirement link flows to the backlink section of HP ALM Requirements, thereby enabling the tester to analyze the requirement of RRC from HP ALM tool. Hence, using standard OSLC specifications, the tester can access all details related to requirements without duplicating the required information in the test management tool.
Kovair Connects Enterprise Architects and RDNG Tool Users
Clients have specific needs. They look into the artifacts that reside in different tools to utilize the workflows, cooperation, reporting as well as maintain consistent administration of issues.
By integrating UML tools like Enterprise Architect and RDNG through OSLC link, Kovair allows the user to link RDNG Requirement with EA Model and Diagram as well as view EA Model and Diagram directly from RDNG.
OSLC provides a key platform that keeps on extending integration capabilities across tools for better data visibility.
Kovair OSLC builds a foundation where different tools can communicate data and artifacts with each other, thereby facilitating tool interaction without needing any additional integration. For more information on Kovair OSLC, visit Kovair Omnibus: OSLC and other Integrations.