Asset Management

The goal of this effort is to define a common set of resources, formats and RESTful services for the use in Asset Management tools and use by Application Lifecycle Management (ALM) and Product Lifecycle Management (PLM) tools.

Asset management systems allow enterprises to catalog, govern, manage, search for, and maintain assets. An asset is anything tangible or intangible that provides value through reference or reuse across a wide audience over an extended period of time such as software, documentation, or representations of equipment. Assets typically have a lifecycle and require a formal process to govern both modification and access, and they may also have relationships to and dependencies on other assets.

Asset Management Charter

Scope

The goal of this effort is to define a common set of resources, formats and RESTful requests for the use in Asset Management tools.

Asset resources define anything tangible or intangible that provides value through reference or reuse across a wide audience over an extended period of time. Assets typically have a lifecycle and require a formal process to govern both modification and access. Cataloging assets with standardized taxonomies controls usage and discovery by end users. Assets may also have relationships to and dependencies on other assets and resources.

Deliverables

The Asset Management Workgroup will produce:

• Scenarios – these will guide the priorities and specification contents within the Workgroup
• Specifications – both maintenance of existing specifications, guidance on usage and new specification
• Supporting and enabling material – on an as-needed basis to support broad adoption

Relationship to other activities and workgroups

Certain specification needs may be found useful and needed by other domain workgroups and therefore may be adopted or endorsed by the Core Workgroup.

This Workgroup will be an active participant within the Core Workgroup as well. The participant will be the Workgroup Lead or a delegate.

For more information, see the Workgroup Best Practices.

Target Specification Development Organizations (SDOs)

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

• OASIS (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

By agreeing to become a member of this WG, this 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.

Each member should expect to:

• attend the teleconferences
• participate in off-line mailing list discussions
• contribute and review scenarios
• participate in prioritization activities
• potentially lead the Workgroup and/or meetings
• 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 typically by teleconference. The frequency changes based on time of year and current cycle of specification development but should expected to 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 provides Workgroup members that can’t attend meetings the ability to participate and provide feedback.

Decision Policy

Decisions within this Workgroup are consensus driven, facilitated by the Workgroup Lead.

The Workgroup members nominate a Lead. Workgroup members work to reach consensus to select the Lead or co-Leads should be. Having more that one Workgroup Lead is preferred but not required.

Intellectual property

Members of this Workgroup agree to this Workgroup Participation Agreement.