© 2013 IBM Corporation OSLC WG Transition **DRAFT** Plan 8 April 2013 Open Services for Lifecycle Collaboration Lifecycle 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 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 open-services.net Three statements of use required OASIS Standard Scope Focus on WG and spec scope definition Draft Create drafts of specifications content Converge WG alignment on key items, call for implementation, test cases Final Positive implementation feedback + 30 day final review No implementation or test case requirement Propose TC with scope IPR Mode Submission Working Draft Committee Specification Draft Committee Specification Public Review Committee Specification  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 weeks6-18 months depending on scope15 – 30 daysPublic review 60 days Member 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 Roadmap Community participation in governance 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 Launch Requires socialization with OSLC community Leverage 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 Steering Committee Workgroups Domain Workgroups Core Workgroup Communications and Advocacy open-services.net Current Steering Committee, Communications and Advocacy open-services.net Other SDOs … OSLC Member Section Steering Committee Workgroups Domain TC Workgroups Subcommittees Liaison Technical Architecture 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. 2014July 2014Oct 2013 Oct 2012 July 2013April 2013 Jan 2013Jan 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 Final 3.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.)important transition considerations 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 Technical Committees Workgroups Subcommittees Member Section enables mapping to open-services.net governance Liaison

© 2013 IBM Corporation General Idea: Transitioning Specification Work to OASIS Steering Committee Workgroups Domain Workgroups Core Workgroup Communications and Advocacy open-services.net Current Steering Committee, Communications and Advocacy open-services.net Other SDOs … OSLC Member Section Steering Committee Workgroups Domain TC Workgroups Subcommittees Liaison Technical Architecture 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