OSLC (Open Services for Lifecycle Collaboration) is an open and extensible framework that accelerates innovation by removing integration bottlenecks between all the disparate applications that contribute to the entire product lifecycle. OSLC replaces highly coupled, proprietary, server-to-server replication integrations with uncoupled, standards-based, “write once integrate everywhere” solutions. Building on WWW standards to define a minimal set of capabilities that support the most common integration scenarios, OSLC defines an approach for resource and capability discovery and UI enablement.

The OSLC vision is to standardize the current set of specifications under the OASIS banner and extend the specification into other domains in the product lifecycle as the need arises. The value of OSLC increases further by leveraging discovery and automation to support full lifecycle processes and governance. Through a bootstrap approach, the ultimate goal of OSLC is to create an ecosystem of integrated applications whose value is much greater than the sum of its parts.

The OASIS-OSLC member section and affiliated technical committees develop specifications and collateral material to promote the OSLC vision. Visit open-services.net for more details.

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.

Integration Toolchains

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.

Federated Shared Information

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.

Taken together these outcomes help foster and encourage development of ecosystems where more tools and solutions are integrated based on open standards, recognized usage scenarios and recurring patterns in order to provide additional value. Through integration, the whole can become much more than simply the sum of the parts.

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.

OSLC (Open Services for Lifecycle Collaboration) is an open and extensible framework that accelerates innovation by removing integration bottlenecks between all the disparate applications that contribute to the entire product lifecycle. OSLC replaces highly coupled, proprietary, server-to-server replication integrations with uncoupled, standards-based, “write once integrate everywhere” solutions. Building on WWW standards to define a minimal set of capabilities that support the most common integration scenarios, OSLC defines an approach for resource and capability discovery and UI enablement.

The OSLC vision is to standardize the current set of specifications under the OASIS banner and extend the specification into other domains in the product lifecycle as the need arises. The value of OSLC increases further by leveraging discovery and automation to support full lifecycle processes and governance. Through a bootstrap approach, the ultimate goal of OSLC is to create an ecosystem of integrated applications whose value is much greater than the sum of its parts.

The OASIS-OSLC member section and affiliated technical committees develop specifications and collateral material to promote the OSLC vision. Visit open-services.net for more details.

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.

Integration Toolchains

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.

Federated Shared Information

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.

Taken together these outcomes help foster and encourage development of ecosystems where more tools and solutions are integrated based on open standards, recognized usage scenarios and recurring patterns in order to provide additional value. Through integration, the whole can become much more than simply the sum of the parts.

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.

Feedback and discussion of the different OSLC Vision topics

How to use this page:
. for new topics: start with “—-” line; add “### title [initials] date”
. for updates: add line with “- [initials] date” and lines with ” - comment”

[TOC]

1. OSLC AND IOT [RE] 2016/02/12

• [RE] 2016/02/12
  • [example:] OSLC should be limited on engineering environments and not be used in IoT target environments because … the underlying concept of OSLC LDP (Linked Data Platform, see…) is very well suited to be used in IoT target systems
• [NN] 2016/02/xx
  • comment

2. Ownership of ‘open-services.net’ [RE] 2016/02/12

• [RE] 2016/02/12

  • currently open-services.net is owned by IBM
  • specification name spaces depend on open-services.net
  • Questions:
    • Q1: should the OSLC community seek ownership?
    • Q2: can it be owned by OASIS-OSLC?
    • Q3: can it be funded by OASIS-OSLC funding?

• [AK] 2016/02/23

  • We need a communication plan / strategy to point interested people to the right content on the right web site
  • open-services.net should be the “community web site” for the entire OSLC ecosystem
  • what content needs to be there?
  • who owns the web site (see topic above) / who pays for it (incl. webmaster, etc.)

• [nn] 2016/0x/xx

  • xxx

3. Executing on the vision [WC] 2016/07/03

• [WC] 2016/07/03
  • The OSLC vision statement paints a compelling picture of how systems should integrate and the necessary standards that need to be in place. Not sure if this belongs in the vision statement, but should we describe in more detail how we envision executing on the next phase? What are the specific outcomes that are desired? Do we need a certain threshold of industry adoption to realize this vision or is it sufficient for the spec to be available for those who want to use it? How to we ensure there is incentive for the community to contribute to the envisioned standards and adopt them? Will OSLC prioritize certain domains over others? This next level of detail will help focus the efforts of the OSLC-MS to achieve this vision.
• [nn] 2016/0x/xx
  • xxx
• [nn] 2016/0x/xx
  • xxx

n. topic template [initals] date copy this template and change number, initials and date

• [nn] 2016/0x/xx
  • xxx
• [nn] 2016/0x/xx
  • xxx
• [nn] 2016/0x/xx
  • xxx

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.

Integration Toolchains

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.

Federated Shared Information

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.

Taken together these outcomes help foster and encourage development of ecosystems where more tools and solutions are integrated based on open standards, recognized usage scenarios and recurring patterns in order to provide additional value. Through integration, the whole can become much more than simply the sum of the parts.

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.

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.

Integration Toolchains

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.

Federated Shared Information

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.

for OSLC Steering Committee Vision Statement see:

[[vision/|http://open-services.net/wiki/steering-committee/vision/]]

please bookmark this page for further references

for OSLC Steering Committee Vision Statement see:

[[OSLC-Vision/|http://open-services.net/wiki/steering-committee/vision/]]

please bookmark this page for further references

for OSLC Steering Committee Vision Statement see:

[[OSLC-Vision/|http://open-services.net/wiki/steering-committee/vision/]]

please bookmark this page for further references

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, 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 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, 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, but this is optional and depends 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.

Integration Toolchains

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.

Federated Shared Information

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

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.

Overview of the OSLC Vision Topics

… what we have collected so far:

• this is unstructured and will be clustered in topics
• topics will be described in separate pages
• the overview of topics will be available in [[ OSLC-Vision-toc | OSLC Vision Table of Content ]]

Backlog

Comment:
preliminary/proposed topics are marked with <prio>
agreed topics are marked with priority <1> … <3>
strikethrough means added to [[ OSLC-Vision-toc | TOC ]] , work in progress or done
The numbers of the backlog list are links to notepad pages for each items.

The should be referred in the TOC with the title of the topic.

Organizational

Technical

other (Action Items)

Input from the 01/2016 Steering Committee Meeting:

Comment:
strikethrough means topic dropped, added to Backlog, work in progress or done (see TOC)

The What…

OSLC vision:

• cover technical as well as organizational topics
• define the scope of OSLC e.g.
  • SW development environments
  • Engineering environments
  • other ?
• address the question:
  • “what is the next big thing in OSLC”
• define how to collaborate with …
  • other members of the MS
  • with other MSs of OASIS
  • with other organizations
• define the position of OSLC in the scope of IoT
• be crisp and clear (for different types of audiences: top management, active members, practitioners, …)

OSLC mission:

• What are we trying to solve or make better, and where do we want or need to get to in the next 2-5 years?
• This is needed to orient ourselves and our initiatives/activities.

The When…

• should start right away.
• A progress timeline should be set. Additional factors to consider:
• Can go public with an initial work-in-progress type announcement aligned with the annual OSLC community update (sometime between May - July… tbd). Invite the community for input at that time.
• Other possible events for announcement:
  • final CRYSTAL event (early-mid June)
  • Incose event (June/July)
  • OSLC Webcast (June/July)
  • other ?
• Need to provide guidance to Communications WG as we make progress so that they can plan for 2016 activities to support the work-in-progress vision and mission.
• Finalization in Q3

The How and Where..

• a core team should work on a draft (to be efficient, the core team should have up to 4 members)
• other StC members and invited participants can provide feedback at any time
• at a later stage (tbd) the whole community should be invited to provide feedback
• a working environment (similar to the OSLC user group environment) shall be installed on opens-services.net with access restrictions to core team, OSLC StC, and some invited contributors; at the later stage, this should be opened up to the whole community. (details of the working environment tbd with Ginny[webmaster]).

Questions:

• how to call the activity?
  • OSLC vision
  • OSLC vision/mission
  • the future of OSLC
• …
• who should/wants to be on the core team?
  • volunteers from the meeting: Bola, Andreas, John, Rainer
  • final definition of the team pending

Overview of the OSLC Vision Topics

… what we have collected so far:

• this is unstructured and will be clustered in topics
• topics will be described in separate pages
• the overview of topics will be available in [[ OSLC-Vision-toc | OSLC Vision Table of Content ]]

Backlog

Comment:
preliminary/proposed topics are marked with <prio>
agreed topics are marked with priority <1> … <3>
strikethrough means added to [[ OSLC-Vision-toc | TOC ]] , work in progress or done
The numbers of the backlog list are links to notepad pages for each items.

The should be referred in the TOC with the title of the topic.

Organizational

Technical

other (Action Items)

Input from the 01/2016 Steering Committee Meeting:

Comment:
strikethrough means topic dropped, added to Backlog, work in progress or done (see TOC)

The What…

OSLC vision:

• cover technical as well as organizational topics
• define the scope of OSLC e.g.
  • SW development environments
  • Engineering environments
  • other ?
• address the question:
  • “what is the next big thing in OSLC”
• define how to collaborate with …
  • other members of the MS
  • with other MSs of OASIS
  • with other organizations
• define the position of OSLC in the scope of IoT
• be crisp and clear (for different types of audiences: top management, active members, practitioners, …)

OSLC mission:

• What are we trying to solve or make better, and where do we want or need to get to in the next 2-5 years?
• This is needed to orient ourselves and our initiatives/activities.

The When…

• should start right away.
• A progress timeline should be set. Additional factors to consider:
• Can go public with an initial work-in-progress type announcement aligned with the annual OSLC community update (sometime between May - July… tbd). Invite the community for input at that time.
• Other possible events for announcement:
  • final CRYSTAL event (early-mid June)
  • Incose event (June/July)
  • OSLC Webcast (June/July)
  • other ?
• Need to provide guidance to Communications WG as we make progress so that they can plan for 2016 activities to support the work-in-progress vision and mission.
• Finalization in Q3

The How and Where..

• a core team should work on a draft (to be efficient, the core team should have up to 4 members)
• other StC members and invited participants can provide feedback at any time
• at a later stage (tbd) the whole community should be invited to provide feedback
• a working environment (similar to the OSLC user group environment) shall be installed on opens-services.net with access restrictions to core team, OSLC StC, and some invited contributors; at the later stage, this should be opened up to the whole community. (details of the working environment tbd with Ginny[webmaster]).

Questions:

• how to call the activity?
  • OSLC vision
  • OSLC vision/mission
  • the future of OSLC
• …
• who should/wants to be on the core team?
  • volunteers from the meeting: Bola, Andreas, John, Rainer
  • final definition of the team pending

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, 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 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, 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, but this is optional and depends 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.

Integration Toolchains

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.

Federated Shared Information

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

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 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.

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.

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, 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 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 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 sufficient 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. Readers are invited to submit ideas for additional domains through the open-services.net forums.

Integration Toolchains

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 messaging systems such as OASIS MQTT to enable easy development of and automation of activities across tools using simple open integration services.

Federated Shared Information

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

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 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 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 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.

Getting Involved

The OSLC 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.

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 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. 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.

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 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 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 sufficient 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. Readers are invited to submit ideas for additional domains through the open-services.net forums.

Integration Toolchains

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 messaging systems such as OASIS MQTT to enable easy development of and automation of activities across tools using simple open integration services.

Federated Shared Information

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

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 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.

Getting Involved

The OSLC 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.

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 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. 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.

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 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 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 sufficient 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. Readers are invited to submit ideas for additional domains through the OASIS or open-services.net forums.

Integration Toolchains

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 messaging systems such as OASIS MQTT to enable easy development of and automation of activities across tools using simple open integration services.

Federated Shared Information

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

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 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.

Getting Involved

The OSLC 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.

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 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. 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.

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 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 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 sufficient 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. Readers are invited to submit ideas for additional domains through the OASIS or open-services.net forums.

Integration Toolchains

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 messaging systems such as OASIS MQTT to enable easy development of and automation of activities across tools using simple open integration services.

Federated Shared Information

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

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 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.

Getting Involved

The OSLC 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

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.

Integration Tool Chains

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.

Federated Shared Information

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.

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.

Integration Tool Chains

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.

Federated Shared Information

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.

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 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.

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.

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.