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; Core Project Area Charter (R19.0)
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
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. | Derek Flexer | |
Customer Centricity | I & O | Ensure consistentcy between the Customer Care type Component Suites and the Customer Centricity program | Cecilia Ortega Lagos | |
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 | Jointly Develop the IoT Device management Component Suite Jointly Develop the Open Digital Lab | Joann O'Brien | |
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. | Robert Walker | |
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 | Joann O'Brien |
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 Henrique Rodrigues | TM Forum 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 | Prepare API Design Guidelines 3.1 | TMF630 Confluence Guidance notes & Swagger generator tool updates Confluence has been updated & the generation tool is being updated: Design Guidelines FAQ and 3.1 Updates
|
| Core |
| ||||
6.01.2 | Prepare & publish API Design Guidelines 3.2 (maybe now refer to as DG 4.0 to align with R18.5 & R19.0 API versions of 4.0?) | TMF630 | Updates to reflect any implications to address "schemification" work done in R18.5 - DG must be agnostic to tooling (vendors must be able to create compliant APIs without access to the tooling) - but in order to support the tooling, we may have introduced conventions which should be reflected here. | Core | |||||
6.01.3 | Scope & roadmap for API Design Guidelines 4.0 (maybe now refer to as DG 5.0 as per above?) | TMF630 roadmap | See 2019-02-12 TAW Tuesday Q2 - API architecture update & input document
| Stretch | |||||
6.01.4 | Update Crowdsourcing template | TMF425 | Move to new TM Forum branding & update to reflect "schemification" and remove references to Orange Enterprise datamodel | Core |
6.02: Road mapped APIs - R19.0 P1s
Workstream Leader: Ludovic Robert
"Schemification of APIs" - Scope agreed at Lisbon Action Week, as per 2019-02-13 TAW Wednesday Q3 - R19.0 API Roadmap & beyond and the results posted back to Confluence here: Open API Catalog - plus there are some new APIs in this list
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.01 | Account Management API | TMF666 | Provides standardized mechanism for the management of billing and settlement accounts, as well as for financial accounting (account receivable) either in B2B or B2B2C contexts | Domain: Engaged Party | Core | Lisbon Team Action Week Feb-2019: Mariano to regenerate for R19.0 L: mar[email protected] M: [email protected] | |||
6.02.02 | Agreement Management API | TMF651 | The Agreement API provides a standardized mechanism for managing agreements, especially in the context of partnerships between partners. | Domain: Engaged Party | Core | Lisbon Team Action Week Feb-2019: Mariano to regenerate for R19.0 L: [email protected] C: [email protected] | |||
6.02.03 | Appointment API | TMF646 | The appointment API provides a standardized mechanism to book an appointment with all the necessary appointment characteristics. The API allows searching of free slots based on parameters, as for example a party, then creating the appointment. The appointment has characteristics such as nature of appointment, place of appointment. | Domain: Customer | Core | Lisbon Team Action Week Feb-2019: Gregore to regenerate for R19.0 L: [email protected], M: [email protected] | |||
6.02.04 | Customer Management API | TMF629 | Provides a standardized mechanism for customer and customer account management, such as creation, update, retrieval, deletion and notification of events. | Domain: Customer | Core | Lisbon Team Action Week Feb-2019: Mariano to regenerate for R19.0 L: [email protected] M: [email protected]@accenture.com | |||
6.02.05 | Trouble Ticket API | TMF621 | Provides a standardized client interface to Trouble Ticket Management Systems for creating, tracking and managing trouble tickets among partners as a result of an issue or problem identified by a customer or another system. Examples of Trouble Ticket API clients include CRM applications, network management or fault management systems, or other trouble ticket management systems (e.g. B2B). | Domain: Common | Core | Lisbon Team Action Week Feb-2019: Jacob to regenerate for R19.0 L: Jacob C: Luis C: Ludovic M: [email protected] | |||
6.02.06 | Loyalty Management API | TMF658 | Supports the management of loyalty program specifications, loyalty program members, their associated products and loyalty accounts with loyalty balances | Domain: Product | Core | Lisbon Team Action Week Feb-2019: Clara to regenerate for R19.0 L: [email protected] M: [email protected] | |||
6.02.07 | Partnership Type Management API | TMF668 | Standardized mechanisms for creating partnership types. It is one of the APIs involved in an onboarding process. Identifies a type of a partnership between parties, including the list of role types that are permitted (i.e Buyer, Seller, Developper). Role types may refer to agreement specifications to be signed by parties playing the role. The API allows the retrieval, creation, update and deletion of partnership type and its owned sub-resources. | Domain: Engaged Party | Core | Lisbon Team Action Week Feb-2019: Mariano to regenerate for R19.0 L: [email protected], M: [email protected] | |||
6.02.08 | Party Management API | TMF632 | Provides standardized mechanism for party management such as creation, update, retrieval, deletion and notification of events. Party can be an individual or an organization that has any kind of relation with the enterprise. | Domain: Engaged Party | Core | Lisbon Team Action Week Feb-2019: Sophie to support during R19.0 L: [email protected] M: [email protected] | |||
6.02.09 | Party Role Management API | TMF669 | A standardized mechanism for general party roles and includes operations such as creation, update, retrieval, deletion and notification of events. Notice that for the management of customers there is a specific Customer Management API. Party Role management API manages the following data resources: PartyRole | Domain: Engaged Party | Core | Lisbon Team Action Week Feb-2019: Mariano to regenerate for R19.0 L: [email protected], M: [email protected] | |||
6.02.10 | Performance Thresholding API | TMF649 | This covers the Threshold aspects of Performance Management, also named Performance Threshold Management or PM Threshold. Provides a standardized mechanism for performance management such as creation, partial or full update and retrieval of the resources involved in performance management (Measurement Production Job, Measurement Collection Job, and Ad hoc Collection). It allows also notification of events related to performance | Domain: Common | Core | Lisbon Team Action Week Feb-2019: Need to confirm ownership with Yuval to regenerate for R19.0 JIRA issues : AP-323 L: Yuval Stein?, C: [email protected] | |||
6.02.11 | Product Catalog Management API | TMF620 | Provides a standardized solution for rapidly adding partners’ products to an existing Catalog. It brings the capability for Service Providers to directly feed partners systems with the technical description of the products they propose to them. | Domain: Product | Core | Lisbon Team Action Week Feb-2019: Jonathan to regenerate for R19.0 L: [email protected] M: [email protected] | |||
6.02.12 | Product Inventory Management API | TMF637 | A standardized mechanism for product inventory management such as creation, partial or full update and retrieval of the representation of a product in the inventory. It also allows the notification of events related to the product lifecycle | Domain: Product | Core | Lisbon Team Action Week Feb-2019: Ludovic to regenerate for R19.0 L: [email protected] M: [email protected] | |||
6.02.13 | Product Offering Qualification API | TMF679 | Product Offering Qualification API is one of Pre-Ordering Management API Family. Product Offering Qualification API goal is to provide Product Offering commercial eligibility | Domain: Customer | Core | Lisbon Team Action Week Feb-2019: Ludovic to regenerate for R19.0 L: [email protected] | |||
6.02.14 | Product Ordering Management API | TMF622 | API provides a standardized mechanism for placing a product order with all of the necessary order parameters | Domain: .Customer Engaged Party | Core | Lisbon Team Action Week Feb-2019: Ludovic to regenerate for R19.0 L: [email protected], M: [email protected] | |||
6.02.15 | Quote Management API | TMF648 | The Quote API is one of the Pre-Ordering Management APIs. The customer Quote API provides a standardized mechanism for placing a customer quote with all of the necessary quote parameters. | Domain: Customer | Core | Lisbon Team Action Week Feb-2019: Ludovic to regenerate for R19.0 L: [email protected] | |||
6.02.16 | Shopping Cart API | TMF663 | Standardized mechanism for the management of shopping carts. Including creation, update, retrieval, deletion and notification of event. Shopping Cart entity is used for the temporarily selection and reservation of product offerings in e-commerce and retail purchase. Shopping cart supports purchase of both tangible and intangible goods and service (e.g. handset, telecom network service). The charge includes the one-off fee such as the fee for handset and the recurring fee such as the fee of a network service. Shopping Cart contains list of cart items, a reference to party or party role (e.g. customer) or contact medium in case of unknown customer, In addition the calculated total items price including promotions. | Domain: Customer | Core | Lisbon Team Action Week Feb-2019: Jacob to regenerate for R19.0 L: [email protected], C: Huawei C: Orange M: [email protected] |
6.03: Road mapped APIs - R19.0 P2s
Workstream Leader: Ludovic Robert
"Schemification of APIs" - Scope agreed at Lisbon Action Week, as per 2019-02-13 TAW Wednesday Q3 - R19.0 API Roadmap & beyond and the results posted back to Confluence here: Open API Catalog
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.01 | Customer Bill Management API | TMF678 | This API allows operations to find and retrieve one or several customer bills (also called invoices) produced for a customer also allows operations to find and retrieve the details of applied customer billing rates presented on a customer bill. | Domain: Customer | Stretch | Lisbon Team Action Week Feb-2019: Could Orange or Amdocs sponsor this? L: [email protected] M: [email protected] | |||
6.03.02 | Geographic Address Management API | TMF673 | Provides a standardized client interface to an Address management system. It allows looking for worldwide addresses. It can also be used to validate geographic address data, to be sure that it corresponds to a real geographic address. Finally, it can be used to look for a geographic address by: searching an area as a start (city, town ...), then zooming on the streets of this area, and finally listing all the street segments (numbers) in a street. | Domain: Common | Stretch | Need to align with GeoJSON and Schema.org for SmartCity work with FIWARE L: [email protected], C: [email protected], C: [email protected] M: [email protected] | |||
6.03.03 | Geographic Location Management API | TMF675 | Provides the information of geographic region of the entity (customer, equipment, address). | Domain: Common | Stretch | Need to align with GeoJSON and Schema.org for SmartCity work with FIWARE L: [email protected], C: [email protected], C: [email protected] M: [email protected] Is Patrick Hils - ESRI engaged? | |||
6.03.04 | Geographic Site API | TMF674 | Covers the operations to manage (create, read, delete) sites that can be associated to a customer, account, service delivery or other entities. This API defines a Site as a convenience class that allows to easily refer to places important to other entities, where a geographic place is the entity that can answer the question “where?” | Domain: Common | Stretch | Need to align with GeoJSON and Schema.org for SmartCity work with FIWARE L: [email protected], C: [email protected], C: [email protected], C: [email protected] M: [email protected] Is Patrick Hils - ESRI engaged? | |||
6.03.05 | Performance Management API | TMF628 | Provides a standardized mechanism for performance management such as the creation, partial or full update and retrieval of resources involved in performance management (Measurement Production Job, Measurement Collection Job, and Ad hoc Collection). It also allows notification of events related to performance. | Domain: Common | Stretch | Lisbon Team Action Week Feb-2019: Pierre/Yuval to regenerate for R19.0 L: [email protected] | |||
6.03.06 | Privacy Management API | TMF644 | The Privacy Management API provides standardized mechanism for privacy profile types, privacy profiles and privacy agreements such as creation, update, retrieval, deletion and notification of events. | Domain: Engaged Party | Stretch | Lisbon Team Action Week Feb-2019: Amdocs to regenerate for R19.0 L: Orange? | |||
6.03.07 | Promotion API | TMF671 | Used to provide the additional discount, voucher, bonus or gift to the customer who meets the pre-defined criteria. Using promotion, the enterprise is able to attract the users and encourage more consumption, especially continuous purchases. Normally Promotion is not regarded as one type of product or product offering. It is often applied when the customer buys the product offerings with the price or amount surpassing the certain limit | Domain: Product | Stretch | Lisbon Team Action Week Feb-2019: Priority 2 (stretch), but needs ownership L: [email protected] | |||
6.03.08 | Recommendation API | TMF680 | Recommendation API is used to recommend offering quickly based on the history and real-time context of customer. It is a real-time and personalized recommendation API. It is usually provided by e-commerce or BSS, CRM system in omni-channel. | Domain: Product | Stretch | Lisbon Team Action Week Feb-2019: Priority 2 (stretch), but needs ownership L: [email protected] | |||
6.03.09 | SLA Management API | TMF623 | Provides a standardized interface for Service Level Agreement (SLA) life-cycle Management (SLA Negotiation, SLA configuration SLA Activation/enforcement, SLA Operations, SLA violation / consequence handling, SLA reporting) between a Customer and a Service Provider which provides offers (product with attached SLA in its catalogue) the customer can discover, browse, trigger and order. | Domain: .Customer Engaged Party | Stretch | Lisbon Team Action Week Feb-2019: Priority 2 (stretch), but needs ownership L: Orange? - Tayeb |
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 component suite? - TR280 - API Component Suite concepts & principals | TR280 TMF426 - template | TR280: Develop further definition for API component suite TMF426: Evolve the API component suite template for consistent application when crowd sourcing component suite definitions | Stretch | Pierre Gauthier | ||||
6.04.2 | TMF909: NaaS component suite | TMF909 | Network as a Service (fka End-to-End NFV Management APIs) | Deliver once R18.5 NaaS related APIs fully released | Johanne Mayer | ||||
6.04.3 | See Joint working with Digital Ecosystems (6.11) for IoT Component Suite | ||||||||
6.04.4 | TMF911: MEF product suite | TMF911 | Possible future component suite | Not for R19.0 | Ludovic Robert | ||||
6.04.5 | TMF912: ONAP product suite | TMF912 | Possible future component suite | Not for R19.0 | Ludovic Robert | ||||
6.04.6 | Service test to Test API | TMF653 | Make DG3.0 and service test becomes a component of test JAD Catalyst APIs | Stretch | Frank Massoudian presented at TAW, Dallas and is working with the team to progress. |
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. | Stretch | |||||||
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 | Core |
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, Knut Johannessen, Henrique Rodrigues
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 | Tool Chain improvements | <Punch list: No formal R19.0 publishable item> | Need to continue the development of the toolchain established in R18.5
| ||||||
6.07.2 | RI/CTK tooling improvements | <Punch list: No formal R19.0 publishable item> | Develop the initial RI/CTK tooling | ||||||
6.07.3 | RI/CTK structure | <Punch list: No formal R19.0 publishable item> | Create RAND GitHub structures | ||||||
6.07.4 | CTK tooling | <Punch list: No formal R19.0 publishable item> | |||||||
6.07.5 | RI tooling | <Punch list: No formal R19.0 publishable item> | |||||||
6.07.6 | Populate CTKs | <Punch list: No formal R19.0 publishable item> | |||||||
6.07.7 | Populate RIs | <Punch list: No formal R19.0 publishable item> |
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 R19.0 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 | TR ONAP TMF API Technical Architecture - Technical paper exploring the technical architecture requirements to support an ONAP service enablement | Stretch | Ludovic Robert |
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.01 | Policy API | TMF693 | Need to be able to create & retrieve policies | Design/SID mapping complete | Stretch | MEF has an interest in Policy (from Fred/Verizon) | |||
6.09.02 | SLA API | TMF623 | SLA api updates - Innova / Turk telecom | Stretch | |||||
6.09.03 | PM/Usage mgt API | TMF628 / TMF635 | Stretch | ||||||
The following, as discussed at Lisbon TAW 2019-02-13 TAW Wednesday Q1 - New API Developments (1 of 2) and 2019-02-14 TAW Thursday Q2 - New API Developments (2 of 2) | |||||||||
6.09.04 | Customer Risk API | TMF696 | PiGa, need to make the UML consistent with product offering qualification, or even merge / enhance it with that? - It is the same structure, don't re-invent. AnPo: Would be good to process through SID first and then build the API on the modified SID? PiGa: complete crowd sourcing template - proceed with the submission into the crowd sourcing. | Stretch | Moshe Zolotov (Amdocs) | ||||
6.09.05 | Number Portability API | TMF698 | Number Portability (Jacob Avraham) | Stretch | |||||
6.09.06 | Sales Management API | TMF699 | Sales Lead API (Ludovic Robert / Grégoire LAURENT) | Stretch | |||||
6.09.07 | Distributed Ledger API | TMF695 | Distributed Ledger API ( Clara van Staden / Pieter Janse van Rensburg) | Stretch | |||||
6.09.08 | The process flow API | TMF701 | The process API (Ludovic Robert) | Stretch | |||||
6.09.09 | Shipping Order API | TMF700 | Shipping Order (Jacob Avraham) - AP-1168TMFxxx Shipping Management REGISTERED In time, this will come to replace TMF684, Shipment tracking, as it will subsume all 684s functionality | Stretch | |||||
6.09.10 | Event management API | TMF688 | Event is any of the action triggered by the human or the system which requires the notification to the other system. | Domain: | Core | Lisbon Team Action Week Feb-2019: Pierre to regenerate for R19.0 L: [email protected] | |||
6.09.11 | Stock Management API | TMF687 | Provides the capability for consumers to search for the stock levels and configuration of one or various Product Offering within Retail Premises (Store) or Storage Premises (Warehouse or Depot). | Domain: | Stretch | Confluence page setup Next Steps: Create a crowdsourcing template L: [email protected], C: [email protected] C: [email protected] |
6.10: 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.10.01 | API Map | GB992 | Summary paper showing all the current and planned APIs, updated periodically as API releases develop | Stretch | Author for most recent R18.0 update: Hongxia Hao Note, may be no new APIs delivered in R19.0, as there were none in R18.5, so an update may be redundant | ||||
6.10.02 | API functional mapping to eTOM & TAM | tba | Mapping functional capabilities of APIs to functions in eTOM & TAM | Stretch | Led by Avi Talmor |
6.11: Joint work with the Digital Ecosystems Project
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.11.01 | TMF908: IoT Device Management Suite | TMF908 Stretch | X-team work to support identification and packaging of the IOT Device Management API Suite Specification: TMF908 Swagger: TBD | CSP, Suppliers & Digital Ecosystem Innovator, ecosystem actors and ecosystem platform developers | Jump start IOT use of TM Forum assets; | Draft published for Team review and approval | Publication of Device Mgt Suite - R19.0 Asset | CSP & Suppliers | |
6.11.02 | IOT Service Management Suite | TMFXXX Stretch | X-team work to support the managaement of IOT service Draft of Specification Swagger (future deliverable) | CSP, Suppliers & Digital Ecosystem Innovator, ecosystem actors and ecosystem platform developers | Jump start IOT use of TM Forum assets; | TBD | Draft of the IOT Service Managmenet Suite - not for publication/ or member review only | Suppliers & CSPs | |
6.11.03 | IOT Data Model | TBD - White paper Stretch | White Paper to describe the Generic IOT Data Model specifications;
Compatible with TM Forum Data Model (TBD) Potential dependency on FIWARE Liason (Smart city) | CSP, Suppliers & Digital Ecosystem Innovator, ecosystem actors and ecosystem platform developers | Jump start IOT use of TM Forum assets; | TBD | White Paper (expoloratory report) | Suppliers & smart city industry organizations | Resources to be staffed. |
6.11.04 | Open Digital Lab | Stretch | Implementation/deployment of the IOT Device Management Suite of deliverables with the Open Digital Lab for use by Catalyst | Catalyst Users
| Jump start IOT use of TM Forum assets; | TBD | Deployment in the Open Digital Lab [Microservice] | Suppliers & Catalyst participants |
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
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