Business Challenge
We live in a dynamic, rapidly changing global world awash in data and hungry for knowledge. Organizations are experiencing extreme pressures for digital transformations in order to collect, communicate, validate, reason about and act on this data for innovative new competitive opportunities. Addressing this pressure requires a flexible, efficient, and effective means of planning, building, operating, assessing and managing potentially complex, rapidly changing, integrated solutions. This in turn puts pressure on engineering and development organizations to utilize methods and tools supporting continuous engineering and continuous delivery in order to quickly respond to new opportunities and close the demand/supply gap.
Lean and agile principles and best practices are being applied to improve development methods, processes and supporting tools. But limited or non-existent integration between tools can create bottlenecks that slow continuous delivery as well as inhibit effective sharing of information for traceability, change and impact analysis. This can lead to increased costs, longer times to value, and potentially lower quality deliverables, all things that increase the demand/supply gap and limit business opportunities.
There have been many efforts over many years to address effective tool integration strategies. However, many of those approaches have resulted in brittle, point-to-point integrations that are very difficult to build, scale and maintain. As a result developers and systems engineers are either limited to a single suite of tools from a single vendor, or have to resort to costly manual import/export and data transform mechanisms to share information across tools. This increases the possibility of errors resulting from data reconciliation issues, and the very bottlenecks in the development process tool integration is intended to address. Integration issues get significantly worse when systems development crosses organizational boundaries and coordination of solution delivery is done in the context of many partners and suppliers potentially using very different methods and tools.
Proposed Solution
The OASIS-OSLC Member Section (OSLC-MS) and affiliated Technical Committee members collaborate to develop standards for capabilities that enable the development of integrated toolchains supporting development methods. These capabilities are defined using standard interfaces based on the proven and ubiquitously adopted World Wide Web architecture. They enable minimally coupled integrations of multi-vendor tools into a pipeline supporting loosely organized, distributed teams. Tool vendors develop their tools independently, at different times, on different technical architectures, using different persistence mechanisms and different data formats. At the same time, tool vendors enable integration with their tools through standard capabilities accessed through standard interfaces and data formats that decouple tools and provide users with flexible tool choice.
Current Integration Capabilities
Current OASIS standards defines a set of discoverable integration capabilities including resource preview, delegated creation and selection dialogs, attachments and resource query. All these capabilities are built on a foundation based on the WWW architecture. HATEOAS (Hypertext As The Engine Of Application State) addresses complexity through standard HTTP interfaces and the REST architectural style as a mechanism for loosely coupled APIs. W3C Linked Data Platform (LDP) and Resource Description Framework (RDF) reduce variability through standard, self-describing, semantically rich, linked data resources leveraged by HATEOAS. OSLC extends LDP to support integration through Minimal, discoverable, self-describing capabilities that enable application integration. For additional details on OSLC v3.0, see OSLC3 Update: What is it, how is it different, and why is it important?.
Envisioned Integration Capabilities
Looking forward, the OSLC-MS envisions a range of initiatives covering shorter term, highly actionable deliverables to longer-term, aspirations. In the near term, the OASIS OCLC Core 3.0, Change Management 3.0, and Configuration Management 1.0 specifications are actively progressing towards OASIS Standard status. These are the first specifications to be migrated from open-services.net to OASIS in order to promote integration standards through an applicable, existing standards body. Other OSLC v2.0 documents on open-services.net are also targeted for migration to OASIS so that all OSLC standards are governed by the same standards body. The OSLC Core 3.0 and Change Management 3.0 specifications add capabilities while leveraging LDP to simplify the REST APIs. Compatibility with OSLC Core v2.0 is maintained in order to foster increased integration and interoperability while preserving existing OSLC investments, ecosystem, and open source projects.
Integration Domains
Another near term deliverable may be guidance on developing, extending and using OSLC domains. OSLC domains are intended to define common vocabulary terms and constraints in order to foster interoperability in and across related domains. There is a tension between over specifying domains and limiting flexibility and under specifying domains with insufficient information. OSLC domain standards are intended to strike a balance by defining common terms to foster integration by avoiding unnecessary variability while being as open and flexible as possible to meet different needs. Vendors and end users are free to leverage, define, extend and integrate OSLC-defined domains. They are also encouraged to develop vocabulary terms and constraints in order to meet their needs. These terms and constraints may become input for future OSLC domain specifications, depending on the specific problems and opportunities being addressed. Regardless OSLC provides capabilities that allow client applications to discover these domain extensions and/or custom vocabularies, and use them in standard ways. However, the best practices and guidelines for developing these extensions may not be sufficient and would benefit from supporting documents, OASIS Committee Notes, common use cases, example implementations and open source projects. These guidelines will also be applicable to the development of new domains such as a Product Definition domains supporting Product Lifecycle Management which has been proposed and may be a future OSLC domain. Readers are invited to submit ideas for additional domains through the open-services.net forums.
A longer term initiative is motivated by the desire to move beyond capabilities that enable integration to additional capabilities that support automation of common integration patterns. This shifts the focus from technologies and standards that enable integration to how they are used to deliver value. Although current integration standards enable tool integration, the activities, work products, governance policies and traceability and impact analysis that arise out of those integrations and across tool would benefit from additional automation. Pushing these capabilities into extensions in the existing tools can result in greater coupling between tools, overlapping implementations, and gaps in functionality that result in poor user experience and increased waste. Rather tools should also be able to be integrated using capabilities that support automation of integration activities in a continuous delivery pipeline.
Integrating tools into an active pipeline that allows people to use their preferred tools while also automating common activities and governance processes across tools requires capabilities such as common event processing systems or reliable messaging though publish and subscribe. The OSLC-MS envisions extensions to the existing OSLC Automation and Actions specifications to utilize relevant messaging systems standards such as OASIS MQTT to enable easy development of and automation of activities across tools using simple open integration services. This would support moving from passive observation of linked data across tools to active full lifecycle processes and governance across integrated tools.
A much more aspirational vision for integration is the establishment of broad communities around federated shared information, and the ability to easily construct role-specific views and viewpoints that enable stakeholders to address their specific concerns. Federation of information has to address multiple dimensions including common vocabularies, distributed access, polyglot data sources, and query. The section “Integration Domains” above describes how different groups could come together to define common domain-specific or corporate ontologies (i.e., shared knowledge models). What is needed is a way to bring together multiple data sources built on different technologies in a manner that represents a single, aggregated, logical data source that supports a common query mechanism.
Resulting Value
OSLC-MS and its Technical Committees help establish a knowledgeable community providing a focal point for integration standards and solutions to be shared and created. These standards define the minimal capabilities that enable just enough integration to meet user needs while minimizing development and integration costs that become barriers to adoption. These communities recognize the variability in problem domains, development and engineering methods, team structure and personal preference that result in the need for heterogeneous toolchains. At the same time, they recognize the value of process, data, service and user interface extensibility and integration required to use those tools in an efficient, effective pipeline for continuous delivery.
Integration capabilities help everyone on the team know what’s going on across the project, because the necessary information is saved, connected, and analyzed. This awareness spurs creativity and innovation based on the real insights gleaned from usage feedback and development experience. This awareness results in understanding the code and everything around it, enabling the team to confidently and safely evolve, replace, and build new capabilities. This awareness is the memory of the project, enabling teams to remember, and new participants to learn what transpired and why. This awareness enables teams to optimize how they work - to rapidly explore new ideas and carefully evolve safety critical components, while being cognizant of interrelationships.
Integration capabilities also help manage federated, shared information to facilitate understanding the information, discovering connections, and enabling predictive analyses. Increased information further increases the team’s ability to understand what to deliver. Increased automation further increases the team’s ability to rapidly deliver. Increased analyses further increases the team’s ability to optimize how to deliver. This can lead to decreased development and maintenance costs, increased reuse, and a greater chance that the right solutions are being built the right way at the right time.
Getting Involved
The OSLC-MS community is seeking your support in order to contribute to the integration vision, and the mission that supports the achievement of that vision. If you have any ideas, or would like to participate in guiding the future direction for integration capabilities and domains, please leverage the open-services.net/participation page to connect with the OSLC community and give us your input.
