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 the improve development methods, processes and supporting tools. But limited or non-existant 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 tool chains 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. RDF (Resource Description Framework) reduces variability through standard, self-describing, semantically rich, linked data resources leveraged by HATEOAS.
Envisioned Integration Capabilities
Looking forward, the OSLC MS envisions a range of initiatives covering shorter term, highly actionable deliverables to longer-term, aspirational visions that may be more difficult to achieve. 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 version 2 documents on open-services.net are also targeted for migration to OASIS so that all OSLC standards are governed by the the same standards body.
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 an limiting flexibility and under specifying domains with insufficient information. OSLC domains 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 extend and integrate existing domains, or develop new domains in order to meet their needs. OSLC provides capabilities that allow client applications to discover these domain extensions and use them in standard ways. However, the best practices and guidelines for developing these extensions may not be sufficiently understood and would benefit from supporting documents, OASIS Committee Notes, common use cases and example implementations. 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.
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 OASIS MS envisions extensions to the existing OSLC Automation and Actions specifications to utilize messaging systems such as MQTT to enable easy development of and automation of activities across tools using simple open integration services such as IBM OpenWhisk, IFTTT and Zapier.
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. This would support moving from passive observation of linked data across tools to active full lifecycle processes and governance across integrated tools.
Resulting Value
OASIS it 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 wile 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 tool chains. 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 knows 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.
