OSLC Configuration Management

DRAFT – This is not yet an official OSLC workgroup - To be discussed with workgroup and Steering Committee

Terminology

Note: this terminology is provisional: the workgroup is tasked with defining the actual terminology.

• Resource: in this context, we refer to an information resource - data that resides on a computer, not an actual physical entity.
• Configuration: a resource that identifies a set of revisions, versions, and/or states of some other resources (the workgroup is to determine if configuration can contain other configurations).
• Configuration management: the practices of managing configurations, their contents, their lifecycles - in particular, identifying and controlling changes to configurations.
• Baseline: an immutable configuration, that is, a snapshot in time of the state of a set of resources, including the links from those resources.

Charter

Produce an RDF vocabulary and associated semantics for configuration management of linked data, capable of addressing the scenarios described below.

In order to keep the specification easy to adopt yet of broad value and appeal, the workgroup is encouraged to avoid constraining the nature of the resources in a configuration, but rather embrace the open principles of linked data, make appropriate use of existing or developing standards such as the Linked Data Basic Profile, refer to other existing vocabularies if appropriate, and be sparing in the number of resource types and REST services required.

Capabilities

The workgroup shall determine the capabilities required to execute the scenarios described below. It is expected, but not absolutely required, that those capabilities include:

• Create and update configurations
• Identify the version of a given resource within the context of a configuration
• Establish a baseline (snapshot) of a configuration
• Describe the contents of a configuration in terms of sets of changes with respect to some other configuration

Other capabilities might be added to this list, if the workgroup decides they are required for full execution of the elaborated scenarios. For example, a client might need to determine the history of the versions of a resource, or to define the effectivity of a configuration in terms of a time range or similar delineation of scope.

It is not intended that this workgroup define capabilities for creation, deletion, and other management of versions of resources other than configurations, baselines, change sets, and other resources defined by the configuration management domain. Specifically not in scope are activities such as placing a resource from some other domain under version control, or (to use SCM terminology) checking such resources in or out.

While the scope of this workgroup does not include all of ITIL or IT Service Management, a configuration as defined by this workgroup shall be able to contain or reference a set of Configuration Items (CIs) and their specific versions, and hence participate in the Identification, Control, and Monitoring activities of ITIL.

Motivation

The OSLC SCM workgroup produced a draft specification for Software Configuration Management, addressing some code browsing scenarios with read-only access. That specification had very limited adoption, partly because the specification was quite complex, involving 16 resource types and several extensions to OSLC core standards, and partly because the specification was seen as addressing only a very narrow range of use cases and problem domains.

During the development of the OSLC SCM draft specification and OSLC Core specification, the OSLC Core workgroup held several discussions about baselines for a general set of linked data resources, but did not complete a baseline extension or separate specification. In the intervening time, the importance of the cross-tool and cross-domain baseline has become increasing evident.

This Configuration Management workgroup shall address these baseline scenarios, providing configurations and baselines for information resources from any domain. It is the intent that the new specification will be less complex than OSLC SCM 1.0, while at the same time enlarged in applicability beyond the software configuration management arena, hence increasing the perceived benefit. To achieve this goal, the specification should allow for low-cost means of integrating tools that already have an existing versioning system, possibly including configurations and baselines, without requiring such tools to re-implement those capabilities. In these cases, the resources to be managed by this cross-tool, cross-domain service may include configurations or baselines defined by existing tools; as such, the service provides composite or aggregate configurations and baselines.

Detailed scenarios and use cases are to be defined and elaborated by the workgroup, but to help provide context to the charter, the use cases are expected to include:

• As a user of a set of OSLC providers, I want to establish a consistent snapshot of the state of resources (a baseline) across all those providers, so that I can record this state for future review and audit.
• As a user of other OSLC services such as Requirements Management, Change Management, Architecture Management, and Quality Management, I want to have traceability of requirements, change requests, design and model elements, and test suites or test cases to the corresponding set of related or dependent changes to other resources (a change set). Note that provision of change sets is expected to be an optional capability in the specification, so as not to exclude simple version management systems such as CVS.
• As a consumer of a set of OSLC providers and their resources, I want to determine if a given resource or change set is or is not included in a given baseline.
• As a quality engineer, or an auditor, I want to compare two baselines so I can see the differences between the two sets of resources and their properties, and hence assess the test needs of, and risks in, the new baseline.

As an example, a composite baseline of OSLC resources might include:

• An oslc_rm:RequirementCollection and the set of oslc_rm:Requirements in that collection, describing the requirements for a particular release of some system
• A set of oslc_am:Resources, describing the use cases and elaborating the designs for the same release of that system
• A set of oslc_qm:TestPlans, oslc_qm:TestCases, oslc_qm:TestResults, etc., describing the tests for the same release of the system

Compatibility

Compatibility with OSLC SCM 1.0 is desired, but not required. An addendum to the SCM 1.0 specification shall be produced describing how to migrate usage of that specification to this Configuration Management specification.

Interactions with other workgroups

The Configuration Management workgroup must collaborate with the PLM-ALM workgroup, producing a specification that satisfies, partially satisfies, or is at least compatible with, the versioning requirements expressed by that workgroup. In order to achieve this, the Configuration Management workgroup must work with the PLM-ALM workgroup to agree on the requirements, scenarios, and the resulting vocabulary.

Deliverables

• Elaborated use cases
• An OSLC Configuration Management specification
• RDF vocabulary documents
• A primer with examples
• Test cases
• An Addendum to OSLC SCM 1.0 describing migration strategies

Schedule

1. Terminology, use cases, and requirements defined by the end of October 2012
2. First draft specification written by the end of December 2012
3. Draft OSLC SCM migration strategy published by February 2013
4. Specification in convergence by the end of March 2013
5. Finalization in June 2013