1. Table of Contents
2. Project Overview
Developing best practices and standards in certain fields greatly benefits from frequent joint work or exchange of live collaboration materials with other TM Forum projects.
To facilitate low-friction collaboration between such projects, this RAND Project Charter is a member of a larger “Core Project Area” which holds the RAND Project Charters; Frameworx (Fx), Open APIs (APIs) & Open Digital Architecture (ODA).
The Core Project Area Project Charter may be seen here; tba
One of the most important sets of assets that the Forum provides to the industry is a set of standard interfaces that enable rapid, repeatable, and flexible integration among operations and management systems.
- Reduce full lifecycle costs of networks and services through use of well documented, consistent interfaces
- Integrate management systems with each other while minimizing cost and risk
- Reduce cycle time for deploying new network equipment with shorter management system integration and test cycles
- Reduce cycle time for getting new services to market with repeatable management systems integration
- Reduce development costs for adding new management capabilities with developer kits and reusable designs and code
- Easily share management information across departments, subsidiaries or with partners
- Creating an agile flexible architecture that is capable of responding rapidly to the needs of the business
The work of the Open API Project is to provide APIs that allow simple and coherent management of any given service and provide developers key design patterns to enable rapid implementation across both the members of the Forum as well as the larger digital ecosystems outside of TM Forum.
Migration of machine readable artifacts to Apache 2.0 license mode in R18.0
It is the TM Forum’s intent to re-issue the existing TM Forum Open APIs under Apache 2.0, many of which were completed in R18 and to release the swagger code for new APIs under the Apache 2.0 license. For clarifcation purposes, the API specification will continue to be released under the RAND license mode. Per the TM Forum Bylaws, we have created a new project and ask all software contributors to existing APIs to join this area with the knowledge that the resulting API swagger files will be published with Apache 2.0 license. The API swaggers will be up versioned and new notice and licensing statements added.
The human readable artifacts (Open API Specifications, Conformance Profiles and SID mapping documents) will continue to be published under the RAND license mode from work carried out under this charter.
Computer readable artifacts (Swagger files) will henceforth be published under the Apache 2.0 license mode under a related but different charter, see: API Apache 2.0 Project (R18.5) - DRAFT
RI's & CTKs will for the time being be released under the RAND license mode.
Given signficant advancements in the CTK development, Postman files are being considered to be phased out as part of R18.5.
All artifacts will be consumable from one place, in the Open API portal, here: Open API Table
The Open Digital Lab will develop in parallel as a new hosted environment where the API instances can be accessed, and consumed in a live sandbox environment. This is specifically designed for catalyst projects in its inital phase.
3. User Stories
Provide a high-level description of how an end-user might use the output of the project.
If desired, copy and paste the table below to create multiple instances of the table and complete it for each user story.
As a.. | |
I need to... | |
So that I can... | |
To do this I need... |
As a.. | TMF member |
I need to... | have a standard means to monitor performance, bill and settle accounts, on-board new partners, order and provision services, and so on |
So that I can... | move quickly in the market and work with the broadest set of vendors, partners and channels |
To do this I need... | a complete set of easily adoptable APIs that are common across both the TMF community and the broader IT ecosystem |
As a.. | Other industry developer |
I need to... | extend and integrate my solutions with telco providers |
So that I can... | bring existing and new products and services to a broad market |
To do this I need... | a rich set of APIs that provide a standard and reasonable means to integrate the various business systems |
As a.. | TMF member |
I need to... | be able to work with all the APIs provided by TM Forum in a consistent and expected manner |
So that I can... | contain costs and deliver solutions in the shortest time possible |
To do this I need... | the APIs from TM Forum to be consistent and follow common patterns that are generally adopted across the wider developer community |
4. Dependencies
Add in other projects and Frameworx dependencies this project will have. Please enter if your project will require INPUT FROM, produce OUTPUT TO or require JOINT WORKING with the named projects/Frameworx. In the COMMENTS column describe the nature of the input, output or joint working.
Project Name | INPUT FROM / OUTPUT TO / JOINT WITH | COMMENTS (describe nature of Input / Output / Joint) | API Contact | Other Project Contact |
---|---|---|---|---|
API-Apache 2.0 | O | API specifications team approved and published to the API-Apache 2.0 project where the Swagger will be constructed | ||
API-Apache 2.0 | I | Once the API-Apache files have been uploaded or edited in the tmforum-apis GitHub organization and been "promoted" to a public copy, this is then ready for review. | ||
Customer Centricity | I & O | Ensure consistentcy between the Customer Care type Component Suites and the Customer Centricity program | ||
Security & Privacy | I & O | Ensure consistentcy between the activities and challanges identified by the security and privacy programs and the relevant future APIs, plus the capture of the application of security & privacy as part of component suite defintion | ||
IOE & Digital Ecosystems | I & O | The IoE API Component suite should evaluate previous scenarios from the IoE program for valid use cases. | ||
DMM | I & O | A review of the technology area of the DMM is required to ensure that it meets the needs of the ODA & API programs. | ||
AI & ML | I &O | Review the advancements by the AI Program for implications to the API program | ||
Frameworx | Joint | API / SID mapping. | ||
Open Digital Arch | Joint | ONAP product suite NaaS product suite | ||
Smart City | I & O | Merging Open Digital APIs with FiWARE APIs - API specification work | Pierre Gauthier |
5. Participants
This section identifies the human resources and skills required by the project to successfully deliver the items listed in this charter. Unless otherwise noted, the level of commitment of all project participants is Best Effort.
At the time the charter is written, the individuals listed below are considered tentative participants. When the charter is approved, the tentative participants will be notified and they can “join” the project in the online community. From that point forward the project resources will be maintained and viewable in real time.
* indicates that this is a required field or role.
Role | Name* | Company* | Confluence “@” mention | Comments |
---|---|---|---|---|
Project Co-Team Lead | Andreas Polz | Infonova | ||
Project Co-Team Lead | Steve Harrop | Vodaphone | Stephen Harrop | |
Mentor | Pierre Gauthier | TM Forum | ||
Sponsor* | Laurent Leboucher | Orange | ||
Subject Matter Expert | Pierre Gauthier | TM Forum | ||
Staff | George Glass | TM Forum |
Role Descriptions & Responsibilities given in section 11
6. Project Workstreams and Deliverables
The project workstreams and deliverables for this project are introduced in the sections below.
6.01: API Design Guidelines
Workstream Leader: Pierre Gauthier, Stephen Harrop
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.01.1 | API Design Guidelines 4.0 | TMF630 <R18.5 => R19.0> |
| ||||||
6.01.2 | Hypermedia Support | <Punch list: No formal R18.5 publishable item> |
|
6.02: API Processes & Governance
Workstream Leader: Stephen Harrop
How do we manage the wide spread of demands, priorities and resource challenges to optimise the delivery and maintenance of the TM Forum Open APIs?
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.02.1 | Schemification Plan | Tiger Team to "schemify" the APIs, in R18.5 the first round was done, based on the APIs required for the NaaS CS (see R18.5 Post TAW updated plan;) For description, see: Componentizing API specs into reusable components Need to identify correct sub-sets of APIs to continue this process, it makes sense to do them in logically consistent sets based around the same key entities. |
| ||||||
6.02.2 | Manage JIRA | <Punch list: No formal R19.0 publishable item> | Manage JIRA backlog, monitor JIRA per API and as part of API reviews, systemetise JIRA views into API review tables |
6.03: Road mapped APIs
Workstream Leader: Andreas Polz
This area of the charter captures the specific APIs that appear to have wide spread industry application and a degree of urgency in their demand for development
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.03.1 | General goal | API Catalogue <Punch list: No formal R19.0 publishable item> | Priority APIs from API roadmap - Clear plans & delivery of all the each step & product ownership to execute on full deliverable set |
6.04: Open API components
Workstream Leader: Pierre Gauthier, Stephen Harrop
How do we build up TM Forum Open API suites, based on use case and requirements analysis, to support specific industry challenges?
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.04.1 | What is a C & P for a conformance suite? - TR280 - API Component Suite concepts & principals | TR280 TMF426 - template <Punch list: => R19.0> | TR280: Develop further definition for API component suite TMF426: Evolve the API component suite template for consistent application when crowd sourcing component suite definitions | Pierre Gauthier | |||||
6.04.2.1 | TR909: NaaS component suite | TR909 <Punch list: => Publish for R18.5> | Network as a Service (fka End-to-End NFV Management APIs) | See detail at: R18.5 Post TAW updated plan; | Johanne Mayer | ||||
6.04.3 | TR908: IoT | TR908 <Punch list: => R19.0> | IoT component suite | Axiata | |||||
6.04.5 | TR911: MEF product suite | TR911 <Punch list: => R19.0> | Possible future component suite | Ludovic Robert | |||||
6.04.6 | TR912: ONAP product suite | TR912 <Punch list: => R19.0> | Possible future component suite | Ludovic Robert |
6.05: API/SID mapping Task Force
Workstream Leader: Cecile Ludwichowski, Michel Besson
How do we ensure that the TM Forum Open APIs, developed by a wide collaboration community and crowd sourced, have a consistent information model and data model view - with each other and with SID?
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.05.1 | White Paper: New overall document - the generalities of how mapped - eg 15 pages for ALL the APIs. | ||||||||
6.05.2 | API / SID mapping plan | Need to reassess how to do API / SID mapping in the light of the new "schemified" API situation | |||||||
6.06: Driving API Adoption
Workstream Leader: George Glass
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.06.1 | API steering committee | <Punch list: No formal R19.0 publishable item> | API steering committee | ||||||
6.06.2 | CSP driven Vendor API adoption assessment | <Punch list: No formal R19.0 publishable item> | CSP driven Vendor API adoption assessment | ||||||
6.06.3 | API Conformance | <Punch list: No formal R19.0 publishable item> | Deploy API Conformance product |
6.07: API Tooling and Automation Support
Workstream Leader: Stephen Harrop, Mariano Belaunde
How do we create a low friction and repeatable way for our collaboration community to create consistent and low effort swagger files, RI & CTK?
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.07.1 | Update to support DG3.1 | <Punch list: No formal R18.5 publishable item> | Update to support DG3.1 | ||||||
6.07.2 | RI/CTK tooling improvements | <Punch list: No formal R18.5 publishable item> | Develop the initial RI/CTK tooling | ||||||
6.07.3 | Tool Chain issues from London F2F | <Punch list: No formal R18.5 publishable item> | Need to continue the development of the RI & CTK tooling, as well as the swagger generator. The team agreed also regarding the swagger and data model publication as well as being "swagger" driven from a tooling perspective.
|
6.08: SDO Collaborations
Workstream Leader: George Glass; Pierre Gauthier;
How do we collaborate with other SDOs build up TM Forum Open API suites to support specific industry challenges?
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.08.1 | MEF support | <Punch list: No formal R18.5 publishable item> | Finalize Part Completed APIs (CTK) New APIs for MEF support - eg trouble ticket | Ludovic Robert | |||||
6.08.2 | ONAP TMF API Technical Architecture | TRnnn <Punch list: No formal R18.5 publishable item> | TR ONAP TMF API Technical Architecture - Technical paper exploring the technical architecture requirements to support an ONAP service enablement | Ludovic Robert | |||||
6.08.3 | OSM, … | <Punch list: No formal R18.5 publishable item> | Currently not actively worked, Volunteers from members welcome to help | ||||||
6.08.4 | ETSI, … | <Punch list: No formal R18.5 publishable item> | Currently not actively managed, however volunteers from members are welcome to help |
6.09: Crowd-Sourced APIs
Workstream Leader: Stephen Harrop, Andreas Polz
This area of the charter is reserved for new APIs that are crowd sourced from members during the year. Members can start the process to submit a new API by submitting a JIRA record with the suggested new API. They will be expected to lead the effort to develop and contribute this API through the defined API Governance process. Any new API work conducted from R19.0 onwards should be consistent with the API schema approach established in R18.5.
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.09.1 | <Punch list: => R19.0> | Reserved for new APIs crowd-sourced from members. | |||||||
6.09.2 | Policy API | TMF693 |
| Design/SID mapping complete | MEF has an interest in Policy (from Fred/Verizon) | ||||
6.09.3 | Product Catalogue API & Rules | TMF620 |
| Design/SID mapping complete | Completed Spec/Swagger, Conformance Profile | R18.5 release on 3-December | |||
6.09.4 | Service test to Test API | TMF653 |
| Frank Massoudian presented at TAW, Dallas and is working with the team to progress. | |||||
6.09.6 | PM/Usage mgt API | TMF628 / TMF635 | |||||||
6.09.7 | Distributed Ledger API | TMF695 | |||||||
6.09.8 | Customer Risk API | TMF696 |
| Moshe Zolotov (Amdocs) | Moshe is working on this on a "best efforts" basis with no guarrantee for R18.5 | ||||
6.09.9 | Stock Management API | TMF687 | |||||||
6.09.10 | Party Management | TMF632 | Will present work to date on | ||||||
6.10: Event Streaming & Messaging
Workstream Leader: Pierre Gauthier
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.10.1 | Event Streaming API | <Punch list: => R19.0> |
|
6.11: RI & CTK Task Force
Workstream Leader: Stephen Harrop
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.11.01 | RI/CTK structure | GitHub structure | Create RAND GitHub structures | ||||||
6.11.02 | CTK tooling | ||||||||
6.11.02 | RI tooling | ||||||||
6.11.03 | Populate CTKs | ||||||||
6.11.04 | Populate RIs |
6.12: API Mapping
Workstream Leader: George Glass
Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
6.12.01 | API Map | GB992 | Summary paper showing all the current and planned APIs, updated periodically as API releases develop | Author for R18.0 update: Hongxia Hao | |||||
6.12.02 | API functional mapping to eTOM & TAM | tba | Mapping functional capabilities of APIs to functions in eTOM & TAM | Led by Avi Talmor |
7. Member Validation and Feedback Approach
Deliverables require validation and feedback. If the development team has a broad range of Members and Service Providers, validation may be within the team, however if the range of Members and Service Providers is weak, after Team Approval, deliverables must be validated beyond the team. Teams must state their Member & Validation approach here:
Validation Activity Approach | Spec Jams |
Validation Activity Description | Face-to-face meetings to resolve & clarify requirements and implementation design, as appropriate to the audience |
Dependencies |
|
Comments |
8. Project Tooling
Indicate the tooling required for project success.
Product | Key Functions | Needed for Project? |
Confluence Space | Document creation and publishing | Provided by default |
JIRA Space | Contribution and feedback management | Provided by default |
GitHub | Code repository (if applicable) | YES |
Other | Public website API Portal | YES |
9. Liaison Relationships
Please indicate if this project has or plans to have a relationship with other External Standards Organizations (SDOs).
Name of Organization | Is this a New or Existing relationship? | Linkages and/or Scope of work | Contact person | Comments |
---|---|---|---|---|
MEF | existing | Sharing API standards |
|
|
FIWARE | existing | Sharing API standards | ||
Eclipse/Papyrus | existing | use of Tooling | ||
Open NFV | Tentative |
10. Charter History
Version | Date | Comment |
---|---|---|
Current Version (v. 3) | Jan 15, 2019 03:35 | Derek Flexer |
v. 20 | Mar 21, 2019 06:28 | Derek Flexer |
v. 19 | Mar 20, 2019 10:22 | Derek Flexer |
v. 18 | Mar 20, 2019 10:04 | Derek Flexer |
v. 17 | Mar 08, 2019 13:15 | Nancy Lyness |
v. 16 | Mar 04, 2019 08:33 | Derek Flexer |
v. 15 | Mar 01, 2019 08:13 | Derek Flexer |
v. 14 | Mar 01, 2019 06:05 | Derek Flexer |
v. 13 | Mar 01, 2019 05:37 | Derek Flexer |
v. 12 | Feb 28, 2019 11:05 | Derek Flexer |
v. 11 | Feb 28, 2019 11:02 | Derek Flexer |
v. 10 | Feb 27, 2019 19:16 | Derek Flexer |
v. 9 | Feb 27, 2019 19:04 | Derek Flexer |
v. 8 | Feb 27, 2019 18:43 | Derek Flexer |
v. 7 | Feb 27, 2019 17:01 | Derek Flexer |
v. 6 | Feb 25, 2019 07:08 | Derek Flexer |
v. 5 | Jan 15, 2019 05:04 | Derek Flexer |
v. 4 | Jan 15, 2019 04:41 | Derek Flexer |
v. 3 | Jan 15, 2019 03:35 | Derek Flexer |
v. 2 | Jan 15, 2019 03:07 | Derek Flexer |
v. 1 | Jan 15, 2019 03:06 | Derek Flexer |
11. Role Definition & Responsibilities
12. Legal Notice
Copyright © TM Forum 2018. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Direct inquiries to the TM Forum office:
4 Century Drive, Suite 100
Parisppany, NJ 07054 USA
Tel No. +1 973 944 5100
fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org