candidates pi2 - UnionInternationalCheminsdeFer/OSDM GitHub Wiki

OSDM: Potential Improvements for PI-2

Andreas Schlapbach (SBB), 04.02.2021

Introduction

As customer and business needs change, the specification needs to evolve continuously. To address the need for improvement the project has been setup in an agile manner. The specification is in in fixed-length time boxes similar to a program increment in the SAFe framework.

During the development of version PI-1 of the working group has identified a set of improvements (their business value is outlined in the next sections):

  • I-3: Add support for partial refund/exchange (Trenitalia/SNCF/Amadeus/BeNe)
  • I-4: Align /locations and /trips to Transmodel (OJP) (SBB)
  • I-7: Add Full Support for PRMs (??? - Needs a Business Owner)
  • I-8: Add Real Time Support (??? - Needs a Business Owner)
  • I-16: Add support to sell non-journey based products (passes) (DB/öBB/SBB)
  • I-18: Combinations of tickets by distributors (SBB/Amadeus)
  • I-19: Add support for tracing (SBB)
  • I-26: Fares should be bundled in the offline data delivery (Offline-Only) (DB)
  • I-28: Add support to query availabilities (Sqills/SBB/ÖBB/DB)

In order for the next PI-2 to optimal support business needs, the business experts of PES and ETT are asked for their input on the proposed improvement as well as additional improvements needed. For the latter, the last page includes a template to formulate business needs.

Road Map

The program increment PI-2 will last from 12.02.2021 to 24.06.2021. The roadmap is as follows:

Roadmap PI-2

Our Improvement Process

A specification as a product which is managed as follows:

  • We have a backlog of improvements where everybody can contribute.

  • An improvement addresses a need and solves a problem, thus producing value.

  • The SPG Working group (NRT/IRT/NT groups) identifies the business needs on behave of the railway undertakings. The business representatives prepare the new requirements with Chairs of OSDM technical Working group. The output is a functional specification document to be examined by the PES (input). On the side the distributors' side, the business needs are identified by Eu Travel Tech (ETT) representatives.

  • The OSDM executive committee (Chair: Marc Guigon & Vittorio Carta) prioritizes the backlog based on the value for the railway customer and the railway sector as a whole. The committee is a fair representation of the parties involved, thus railways and distributors and others.

  • The OSDM technical working group (Chair: Clemens Gantert & Andreas Schlapbach) designs and implements improvements to the standard. Thus, it is responsible to translate the functional specification identified by the SPG/PES and ETT into a document of technical specification. To stay focused, the work in progress should not be larger than seven items. The working group takes special care not to break existing implementations, thus securing investments made by all the parties.

  • The PES endorses the functional & technical specifications prepared by the OSDM Technical WG, preparing the agenda of the OSDM executive committee. Similarly, ETT endorses the improvements prepared.

Illustration of the concepts:

Organization

Structure of an Improvement

An improvement is structured similar to an epic in the SAFe framework as follows:

  • Name: Short name for the improvement

  • Owner: Name of the owner

  • Description "For customers who do something the solution is a improvement that provides this value unlike current solution or non-existing solution our solution does something better."

  • Business Value: The business value which is generated after the improvement has been implemented (low/middle/high).

  • Business Outcomes: The measurable benefits that the business can anticipate if the epic hypothesis is proven to be correct.

  • Leading Indicators: The early measures that will help predict the business outcome hypothesis.

  • Non-functional Requirements: If a business requirement has critical non-functional constraints they should be noted here.

  • Specification Effort: An assessment of the effort to specify the improvement (EXTRA_SMALL, SMALL, MEDIUM, LARGE).

State of an Improvement

An improvement takes the following steps:

  • An improvement is in the initial state proposed.
  • The steering board then decides which improvements to analyze based on their business value → state accepted for analysis.
  • The technical experts then analyses the improvement and determine its complexity (low/middle/high). After their work the improvement is in state analyzed.
  • The steering board decides which improvements are to be implemented based on a transparent prioritization model (e.g. Weighted Shortest Job First) → state accepted for design.
  • The technical experts then design the solution, thus the API, the documentation and the test sets. After their work the improvement is in state designed.
  • The steering board releases major, i.e. breaking changes → the improvement is published.

Working Mode

The technical working group meets online every Friday from 9:00 to 11:00. Participation is open to everybody and highly encouraged. If you wish to join, please contact Schlapbach Andreas.

The meeting minutes as well as future improvements are documented in the GitHub Wiki.