© 2013 IBM Corporation

OSLC WG Transition **DRAFT** Plan

8 April 2013

Open Services for Lifecycle CollaborationLifecycle integration inspired by the web

© 2013 IBM Corporation

Important Transition Considerations

Minimize disruption to specification development with transition aligned with specification finalization

Start Member Section before specifications move

OSLC Core is the initial technical work to transition to new TC

– Linked Data portion goes to / remains with W3C

Additional TCs formed as OSLC domain specs start finalizing

– (may be submitted to other orgs if appropriate)

2

© 2013 IBM Corporation

OASIS Member Section & Technical Committee Creation

3

Member Section

• Appoint “MS proposal team” to draft statement of work, rules of procedure, and schedule

• Procedures and initial steering committee mapped to current OSLC governance

• Submit proposal to OASIS with at least 5 members

• OASIS board approval

• Create Member section, form steering committee, associate TC’s

Technical committee

• Domain group appoints submission team to draft TC charter scoping work, defining deliverables and timing

• Finalizing specification at http://open-services.net to submit as basis for work product

• Submit proposal with specification reference to OASIS with at least 5 people from 2 companies, time and location for first meeting

• Identify nominees for chair, editor for election at first meeting

© 2013 IBM Corporation

WG Transition Considerations

When transitioning, it is an opportunity to reconsider the scope and charter of existing WGs

Due to OASIS TC requirements of having at least 5 members (from at least 2 companies) to launch a TC…

– Either we need to recruit new members that previously have not been in WGs

– OR…we combine WGs into a single TC

• These single TCs may produce multiple specifications or resource definitions

– Concern of perception if only 2 companies…more of a Steering Committee decision

If a WG is done or won’t be very active, leave at open-services.net

Completed specifications and history will remain at open-services.net

© 2013 IBM Corporation

OSLC Member Section

Scope Draft Converge Final

Core 3.0

Change Management 3.0

Configuration Management

Requirements Management 3.0

Asset Management 3.0

Quality Management 3.0

Architecture Management 3.0

Estimation and Measurement

PLM/ALM

Automation 3.0

Performance Monitoring 3.0

Resource Reconciliation 3.0

Event Monitoring 3.0

Change and Configuration Management TC

Reqs and Quality Management TC

Linked Data Platform WG

Core TC

Project and Portfolio Management TC

Automation TC

Integrated Service Management TC

1a

1b

0

2a

2b

2c

3

4

Once Member Section is created and Core is transitioned, domains transition independently

Domain Specific / Other Standards Body 5

5

Proposed Technical Committees and Mapping to WGs

© 2013 IBM Corporation

OASIS Specification Process Mapping

6

Iterate Iterate

open-services.net

Three statements of use required

OASIS Standard

ScopeFocus on WG and spec scope definition

DraftCreate drafts of specifications content

ConvergeWG alignment on key items, call for implementation, test cases

FinalPositive implementation feedback + 30 day final review

No implementation or test case requirement

Propose TC with scopeIPR ModeSubmission

Working Draft

Committee Specification Draft

Committee Specification Public Review

CommitteeSpecification

Both processes support iterative development and incremental IPR commitments based on membership in work groups/technical committees

Progression to OASIS Committee Specification is based on TC member vote, timing depends on scope, group consensus – 12 – 24 months typical

OASIS Member Section rules of procedure allow for additional coordination across work groups

8 weeks 6-18 months depending on scope 15 – 30 days Public review 60 daysMember vote 14 days

© 2013 IBM Corporation

OSLC Core After the Transition

Becomes “Core TC”

Oversee common technical approach of OSLC

Continue to focus on cross-domain needs/guidance

Will produce specifications

Works to divert key items to appropriate SDO: W3C, OASIS, IETF, …

– W3C: Resource, Container (Paging, Ordering), Shapes?

– OASIS: Query, Delegated UIs, Discovery, common vocabs

7

© 2013 IBM Corporation

Process and timing depends on status at open-services.net

Review domain scope and status to determine how to structure TC formation

• Domains may be combined into TC’s (as separate deliverables)

Final

• Submit final specification to a new or existing TC

Draft Converge

• Complete the specification development at open-services.net

Scope Phase

• OSLC Steering Committee approves transfer to OASIS Member Section subcommittee

• OASIS Member Section Steering Committee approves creation of new subcommittee

• Subcommittee completes requirements analysis and proposes project scope

• OASIS Member Section Steering Committee charters new TC using standard process

8

OSLC Workgroups Transition Options

© 2013 IBM Corporation

backup

© 2013 IBM Corporation

OSLC Community Governance RoadmapC

omm

unity

par

ticip

atio

n in

gov

erna

nce

Previous State: IBM Provides de facto governance (with support)

Current State(Intermediate Step)-Steering Committee established - New governance model introduced-Governance will be tweaked iteratively

Future State … ?•Potential Formal independence ?•Recognized formal standard development organization?•…

Time

What next?When?

(adapted from the governance update documents shared with the community)

10

© 2013 IBM Corporation

Transitioning OSLC specifications to a standards org will lower barrier to adoption Vendor neutrality helps attract both product developers and users (e.g. CA, Siemens, VMWare) Evolve OSLC investment with open-services.net advocacy group

OASIS structure is compatible with current OSLC approach, some changes required Differentiate specification development from use cases, scenarios or requirements New version content will require agreement from WG members Limited ability to move content between organizations

Plan Mid-Year LaunchRequires socialization with OSLC communityLeverage 1H 2013 conferences for recruiting Proposed timeline paced to move specs in a measured, deliberate manner Recruit additional vendors for OASIS and additional users for open-services.net

SteeringCommittee

Workgroups Workgroups DomainWorkgroups

CoreWorkgroup

Communicationsand Advocacy

open-services.net

Current

Steering Committee, Communications and

Advocacy

open-services.net

Other SDOs…

OSLC Member Section

Steering Committee

Workgroups Workgroups Domain TC

Workgroups Workgroups Subcommittees

Liaison

TechnicalArchitecture TC

Proposed Future

OSLC in OASIS Member section provides

oversight Specifications developed in TC

on standards track Incubation activities (non-

specification) in subcommittees OSLC specifications or

proposals from subcommittees may go to other organizations

Open-services.net continues for communications and advocacy Focus on usage vs writing specs

11

OSLC Standardization Proposal - Summary

© 2013 IBM Corporation12

April. 2014 July 2014Oct 2013 Oct 2012 July 2013April 2013 Jan 2013 Jan 2014

Launch Core TC

Core TC Meeting

open-services.net

First MS Meeting

Launch MS.

OASIS Board Approval

Additional TCs formed as domain specs reach final

OSLC StC Planning

Core LD work to W3C LDP

3.0 Final3.0 Converge3.0 specs Development

Recruit New Members

OSLC StC Plan Execution Oversight

Launch mid-year, communication/recruiting plan includes less formal announcements prior to this

Preparation for transition starts immediately

TC’s formed as OSLC core and domain specs reach final stages

W3C LDP WG milestones: last call draft 5/2013, Candidate Rec 10/2013, Rec 3/2014

(See also “important transition considerations” for rationale for this time frame.)

Timeline for Transitioning OSLC V3

© 2013 IBM Corporation

Standards Organization Synergy with open-services.net

13

Formed to allow existing organizations or initiatives to become part of OASIS, while maintaining their identity and governance through the Member Section Steering Committee

• Coordinates activities across one or more TCs

Establishes liaisons with other groups

Member Section Rules of Procedure define Statement of work Structure for steering committee Provisions for affiliated TC’s

Member Section subcommittees established by steering committee to advise on the work of the Member Section; e.g. use cases, requirements. IP development requires the TC process

Affiliated Technical Committees drive standards

OASIS Member Section

Member Section Steering Committee

Workgroups Workgroups Technical

Committees

Workgroups Workgroups Subcommittees

Member Section enables mapping to open-services.net governance

Liaison

© 2013 IBM Corporation

General Idea: Transitioning Specification Work to OASIS

SteeringCommittee

Workgroups Workgroups DomainWorkgroups

CoreWorkgroup

Communicationsand Advocacy

open-services.net

Current

Steering Committee, Communications and

Advocacy

open-services.net

Other SDOs

…

OSLC Member Section

Steering Committee

Workgroups Workgroups

Domain TC

Workgroups Workgroups Subcommittees

Liaison

TechnicalArchitecture TC

Proposed Future

OSLC in OASIS Member section provides oversight Specifications developed in TC on standards track Incubation activities (non-specification) in subcommittees OSLC specifications or proposals from subcommittees may go to other

organizations

Open-services.net continues for communications and advocacy Focus on usage vs. writing specs

14