Configuration Management

A common vocabulary for versions and configurations of linked data resources. For example, identifying the version of a resource in a configuration, defining baselines (or snapshots) of a configuration, and handling changes systematically over time.

Configuration Management Charter

Scope

Produce an RDF vocabulary and associated semantics for configuration management of linked data, capable of addressing the scenarios described below, covering resources in multiple OSLC domains.

The resulting specification is intended to satisfy cross-cutting domain scenarios (see OSLC Core WG's list of "Common Specification Efforts").

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.

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

Capabilities

As with most OSLC domains, the specification is to be developed incrementally, adding new scenarios and capabilities over time. For the first iteration, 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.

For this first iteration, 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 for the first iteration 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. Subsequent iterations may extend the specification to include such scenarios.

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. Subsequent iterations of the Configuration Management specification may address more compatibility with and extensions to the capabilities in the SCM 1.0 draft. It is also possible that use cases will be found that are considered specific to file-based source control that will not be included in the Configuration Management specification, but might be addressed by a different vocabulary produced by a future SCM workgroup.

Relationship to other activities and workgroups

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

For more information, see the Workgroup Best Practices.

Target Specification Development Organizations (SDOs)

Specifications developed by this WG may be contributed to these SDOs:

• W3C (IP Policy)
• OASIS (IP Policy)
• DMTF (IP Policy)
• OMG (IP Policy)

This contribution to these SDOs is dependent on maturing the specifications within this WG and gaining consensus on the contribution. At that point, the WG would make a proposal to the OSLC Steering Committee for such a move. For more information, see the Workgroup Best Practices.

Participation

Agreeing to become a member of this Workgroup implies some amount of time and contribution to assist in the development and promotion of the specification. There is no minimal amount of time or level of participation.

In so far as they are able, members of the Workgroup should contribute in the following areas:

• attend the teleconferences
• participate in off-line mailing list discussions
• contribute and review scenarios
• participate in prioritization activities
• contribute specification content in the form of proposals and actual specification text
• edit and organize the specification
• address specification issues
• contribute to a test suite
• produce implementation feedback in form of implementation reports

Meetings Frequency and Communications

Meetings are conducted by teleconference. The frequency may vary based on time of year and current cycle of specification development, but will normally be every two weeks. Additional meetings may be held by a subset of the Workgroup on a more frequent basis to work on some focused activities.

Meetings should be announced at least 48 hours in advance. Meeting agendas should be set at least 24 hours in advance.

Mailing list and wikis should be used to capture all work and discussions. This allows Workgroup members who cannot attend meetings to participate and provide feedback.

Decision Policy

Decisions within this Workgroup are consensus driven, facilitated by the Workgroup Lead. The Workgroup members nominate and reach consensus on the Lead.

Intellectual property

Members of this Workgroup agree to this Workgroup Participation Agreement.