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.
The Core IPR Container Project Charter may be seen here; Core Project Area Charter (R18.0)
One of the most important parts that the Forum provides 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 putting new network equipment in service 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
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. Per the 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 APIs will be published with Apache 2.0 license. The APIs will be up versions 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, Postman files, RI/CTKs) will henceforth be published under the Apache 2.0 license mode under a related but different charter, see: API Apache 2.0 Project (R18.0)
Both sets of 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.. | OTT developer |
| I need to... | extend my solutions into a number of TM Forum members |
| 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, Postman, RI and CTKs will be constructed | ||
Analytics | x | |||
| Customer Centricity | x | |||
| DMMM | x | |||
| ODA |
|
| ||
| Frameworx | Joint | To cover governance | ||
| Metrics | x | |||
| IoE | x - nothing in R17.5 | Blockchain lab? - Is there scope for complementary work? - Future work | Andreas Polz | |
| Smart City | x | Andreas Polz | Washington Tavares | |
| ZOOM + Hybrid Network Platform | IOJ | Joint calls set up with API & ZOOM |
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 | ||
| Mentor | Pierre Gauthier | TM Forum | ||
| Sponsor* | Laurent Leboucher | Orange | ||
| Subject Matter Expert | Pierre Gauthier | TM Forum | ||
| Staff | Joann O'Brien | 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:
| 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 | DG4.0 - support for messaging & streaming | ||||||||
| 6.01.2 | New swagger template | ||||||||
| 6.01.3 | Tie in the Tosca service definition with our catalogue management APIs |
6.02: API Processes & Governance
Workstream Leader:
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 | Need to tie up the technical architecture with stronger governance - all deliverables - 25% have no postman - clear plan & priority to complete existing and clarity of requirements for new ones. |
6.03: Road mapped APIs
Workstream Leader:
How do we ensure that the TM Forum Open APIs, planned to be developed in the API roadmap, are brought to full implementation; spec, CP, SID mapping, swagger, 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.03.1 | 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:
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 CP for a conformance suite | TRnnn - API Component Suite concept & principal | TR: what is an API component suite | ||||||
| 6.04.2 | TR: NaaS component suite | Network as a Service (fka End-to-End NFV Management APIs) | |||||||
| 6.04.3 | TR: IoT | IoT | |||||||
| 6.04.4 | TR: CM | Customer Management |
6.05: API/SID mapping Task Force
Workstream Leader:
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 | Existing mappings continue | ||||||||
| 6.05.2 | White Paper: New overall document - the generalities of how mapped - eg 15 pages for ALL the APIs. |
6.06: Finalize Part Completed APIs (API Spec + CP + API/SID mapping)
Workstream Leader:
How do we ensure that the TM Forum Open APIs, developed by a wide collaboration community, are brought to full implementation; spec, CP, SID mapping, swagger, 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.06.1 | Outstanding items & priority as set by 6.02 - Complete the API table for existing APIs |
6.07: API Tooling and Automation Support
Workstream Leader:
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.0 |
6.08: SDO Collaborations
Workstream Leader:
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 | Finalize Part Completed APIs (CTK) New APIs for MEF support - eg trouble ticket Apache version of MEF API | |||||||
| 6.08.2 | ONAP TMF API Technical Architecture | TR | TR ONAP TMF API Technical Architecture | ||||||
| 6.08.3 | OSM, … | ||||||||
| 6.08.4 | ETSI, … |
6.09: Catalog Management
Workstream Leader:
How do I, as service provider or vendor partner utilize enterprise catalogs to enable product offer creation in an open, efficient and easily understood manner?
| 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 | (NaLy?) |
6.10: Crowd-Sourced APIs
Workstream Leader:
How do we ensure that the TM Forum Open APIs, developed by a crowd sourced community, are brought to full implementation; spec, CP, SID mapping, swagger, 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.10.1 | Clear plans & delivery of all the crowd source phases & review of each step & product ownership to execute on full deliverable set |
6.11: API map
Workstream Leader:
How do we create a short, medium and long term view of how we address the demands and priorities for developing 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.11.1 | ? |
6.12: Open MicroServices and APIs
Workstream Leader:
How do we create industry leading and technologically leading APIs that have design patterns that are optimised for the cloud based ecosystem?
| 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.1 | Technical recommendation on how to best use Open APIs within the context of a microservices architecture - how to use the APIs to front the microservices architecture |
| The following entries are from the R17.5 charter and are left in for the moment simply as a reference to pull from as we build up detail in the R18.0 version of the charter |
|---|
6.1. OLD 17.5 Workstream 1: RI & CTK Task Force
Workstream Leader: Andreas Polz
| 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 |
| 1.1 | Enhanced tooling | Per API - RI in IBM Bluemix & CTK in Github <STRETCH> | Partially automated generation of RI in IBM Bluemix environment and CTK output | API Developers | To help bridge the gap from API spec, Swagger & conformance profile to full RI/CTK support | Dependent on 1.3 being resourced | |||
| 1.2 | Immediate fixes | Tooling fixes <CORE> | Implement fixes for problems identified at TAW and Fork code generator to "land" version in TMF Private Github space | API Developers | Complete by end October | ||||
| 1.3 | Implementation proposal | Enhanced tooling support <CORE> | Project to enhance prototype tooling to remove most manual steps and make "smarter" | API Developers | De-skill using the tooling | Put to CSC, 10/Oct/17 | |||
| 1.4 | Prioritised plan | Priorotised list of APIs to process <CORE> | Task force to review all APIs and establish "attack list" to deliver working groups of APIs | API programme | To ensure effort is focused to best effect | StHa compiling plan | |||
| 1.5 | Per-API RI/CTK | Completed RI/CTKs | In parallel with enhancing the tooling, process most urgent APIs with prototype tooling | API Developers | Start to complete RI/CTK set | StHa will work with Grad in VF, possibly others also |
6.2. OLD 17.5 Workstream 2: End-to-End NFV Management APIs
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 |
| 2.1 | Review requirements at TAW <CORE> | Agreement between API and ZOOM teams | Meet & agree at TAW | ZOOM Team, API Team | COMPLETE, TAW <Zoom/API, Thursday Q1/Q2> | ||||
| 2.2 | RFAC API (Service) and RFAC API (Resource) | TMFxxx, TMFyyy | RFAC API (TMF664) be split into two parts - Service Activation and Resource Activation | Consumers of NFV related APIs | |||||
6.3. OLD 17.5 Workstream 3: API Design Guidelines
Workstream Leader: Nicoleta Stoica
| 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 |
| 3.1 | Hypermedia & Microservice definition | TMF630 | Design Guidelines v3.0 to support Hypermedia & Microservice definition | API Project Teams working on new API's | Specify new API's | Release early in cycle so other APIs may produce compliant versions | Vodafone, Infonova, Infosys, Orange, Pierre Gauthier | ||
| 3.2 | Concepts & Principals | Update C&P document to reflect use of suits of APIs, when used together, to deliver a capability |
6.4. OLD 17.5 Workstream 4: API Processes & Governance
Workstream Leader: Stephen Harrop, Joann O'Brien
| 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 |
| 4.1 | Issue Backlog | StHa | |||||||
| 4.2 | API Table management | Control the contents of the Open API Table to ensure data is correct and up to date | API Team | Publication of Released and Beta Open APIs | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.3 | API Catalog management | Ensure that data is up to date and synchronized with Open API Table. | API Team | More detailed management of API development deliverables | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.4 | API identification – numbering method | Management of the numbering identification of new and existing APIs | API Team | Managed API indentification | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.5 | Artefact version control | Ensure artifacts are correctly versioned using GitHub for all version management (documentation and software) | API Team | Version management process definition | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.6 | Swagger repo management | Move / manage API Swagger development on current TMF Swagger environment | API Team | Artefact management process definition | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.7 | GitHub integration with Swagger | Management of Swagger artifacts using GitHub | API Team | Artefact management process definition | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.8 | API documentation management | Management of the quality and issue of the Open API documentation | API Team | Document management process definition | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.9 | API Project Conformance space management | Ensuring that the Conformance space is managed effectively and coordinated with contributing members | API Team | Confluence space and page management | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.10 | Release management with JIRA | Set up the Release Management process using JIRA | API Team | Release management | Delivery in first 90 days | Ongoing management | API Team | PeNo | |
| 4.11 | Use of JIRA with GitHub | Make better use of JIRA capability and tracking of changes to APIs and provide better release management | API Team | Release management | Delivery in first 90 days | Ongoing management | API Team | PeNo |
6.5. OLD 17.5 Workstream 5: API/SID mapping Task Force
Workstream Leader: Cecile Ludwichowski
| 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 |
| 5.1 | Mapping Rules & Template | Document (number(s)?) | Maintain and continually update mapping rules as work uncovers clarifications or enhancements | API Developers, Data modellers | On-going as required. Basline in place created in R17. Internal project document. | ||||
| 5.2 | API / SID mappings completed | TMF637A, TMF646A | Mapping completed, SID and API CRs raised | TMF637A (Jonathan Goldberg), TMF646A (Yaniv Gigi) | |||||
| 5.3 | API / SID mappings in progress | TMF622A, TMF629A, TMF636A, TMF645A, TMF658A, TMF663A, TMF662A | TMF622 - Product Ordering (Calogero), TMF629 – Customer: Patricia (Accenture), TMF636 – Customer Bill Management (Cécile), TMF645 - Service Qualification: Atif (Infosys), TMF658 - Loyalty: Narayanan Krishnamurthy (Infosys), TMF663 - Shopping Cart (Jonathan), TMF662 - Entity Catalog: Kamal Maghsoudlou (Ericsson) | ||||||
| 5.4 | API / SID mappings with assigned mappers | TMF621A, TMF639A, TMF640A, TMF654A, TMF666A, TMF668A, TMF669A, TMF620A | TMF621 – Trouble Ticket: Yaniv Gigi (Amdocs), TMF639 - Resource Inventory : Jonathan (Amdocs), TMF640 - Service / Resource configuration & Activation: Atif Husain (Infosys), TMF654 – Prepaid Balance: Jonathan (Amdocs), TMF666 - Account Management: Cécile (Orange), TMF668 - Partnership type (previously named Onboarding): Michel Besson (TMForum), TMF669 - Party Role: Cécile (Orange), TMF620 – Product Catalog Management (Kamal), TMF635 – Usage Management (Luis) | ||||||
| 5.5 | API / SID mappings as yet unassigned | TMF647A, TMF651A, TMF655A, TMF667A, TMF632A, TMF671A, TMF652A, TMF638A, TMF657A, TMF653A, TMF623A | TMF647 – Address,TMF651 – Agreement, TMF655 – Change, TMF667 – Document, TMF632 – Party, TMF671 – Promotion, TMF652 – Resource Order Management, TMF638 – Service Inventory Management, TMF657 – Service Quality, TMF653 – Service Test, TMF623 – SLA Management | ||||||
6.6. OLD 17.5 Workstream 6: Finalize Part Completed APIs (API Spec + Swagger)
Workstream Leader: Andreas Polz
| 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.1 | PaymentManagement API | TMF676 | PaymentManagement API |
|
|
| 16/Oct - in Team Review | ||
| 6.2 | Product Catalog Management API | TMF620 | Product Catalog Management API | 16/Oct - in Team Review | |||||
| 6.3 | Service Catalog Management API | TMF633 | Service Catalog Management API | 16/Oct - in Team Review | |||||
| 6.4 | UsageConsumption API | TMF677 | UsageConsumption API | 16/Oct - in Team Review | |||||
| 6.5 | GeographicAddress API | GeographicAddress API | 16/Oct - in Team Review | ||||||
| 6.6 | GeographicLocation API | TMF675 | GeographicLocation API | 16/Oct - in Team Review | |||||
| 6.7 | GeographicSite API | TMF674 | GeographicSite API | 16/Oct - in Team Review | |||||
| 6.8 | Customer Bill Management API | TMF678 | Customer Bill Management API | 16/Oct - in Team Review | |||||
| 6.9 | Quote Management API | TMF648 | Quote Management API | 16/Oct - in Team Review |
6.7. OLD 17.5 Workstream 7: API Tooling and Automation Support
Workstream Leader: Mariano Belaunde
| 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 |
| 7.1 | EA UML front end | Software - | The EA profile component to edit the API Specification in UML, including the textual-based API rules | ||||||
| 7.2 | EA Generator Connector | Software - | The facility that will allow the pre-existing swagger and spec generators (developed by Orange) to use the UML model edited with the UML front end | ||||||
| 7.3 | EA Integrated UML Tooling | Software and document (TRXXX) - | The packaging of the tools – including the documentation – that will allow “self-service” usage by the API designers. |
6.8. OLD 17.5 Workstream 8: MEF support - Finalize Part Completed APIs (CTK)
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 |
8.1 | Process MEF CR list |
| Support for MEF LSO SDK "Sonata" v1 |
|
|
|
|
|
|
| 8.2 | GeographicSite API | TMF674 | TMF674 GeographicSite API | ||||||
| 8.3 | GeographicAddress API | ||||||||
| 8.4 | Product Ordering Management API | TMF622 | TMF622 Product Ordering Management API | ||||||
| 8.5 | ProductOfferingQualification API | TMF679 | TMF679 ProductOfferingQualification API |
6.9. OLD 17.5 Workstream 9: Roadmapped APIs
Workstream Leader: Andreas Polz
| 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 |
9.1 | IoT Management API |
| IoT Management API (including revenue mgt & payment capabilities) – needs potential usage report (10 pages) |
|
|
|
|
|
|
| 9.2 | IoT Data API | IoT Data API | |||||||
| 9.3 | Payment Management APIs | Payment Management API Series | |||||||
| 9.4 | Digital Service Management API | Digital Service Management API | |||||||
| 9.5 | Event Stream API | Event Stream API | |||||||
| 9.6 | Smart-city API gaps | Smart-city API gaps | |||||||
| 9.7 | Resource Pool | ||||||||
| 9.8 | Communication API | TMF681 | Communication API | 16/Oct - in Team Review | |||||
| 9.9 | Recommendation API | TMF680 | Recommendation API | 16/Oct - in Team Review |
6.10. OLD 17.5 Workstream 10: Crowd-Sourced APIs
Workstream Leader:
| 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 |
10.1 | Onboarding (new) | TMFXXX - stretch |
|
|
|
|
|
| |
| 10.2 | Shipment tracking management API | Stretch | Shipment tracking management API | ||||||
| 10.3 | User interactions management API | Stretch | User interactions management API |
6.11. OLD 17.5 Workstream 11: API map
Workstream Leader: Nicoleta Stoica
| 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 |
|---|---|---|---|---|---|---|---|---|---|
| 11.1 | API map updates | GB992 - core | Update of API map to take into account APIs published with release 17.5 | TM Forum members | yes | Huawei | |||
| 11.2 | Deployment / usage view | GB992 - core | Finalize deployment view section | TM Forum members | yes | Huawei | |||
| 11.3 | Alignment with Frameworx | GB992 - core | Continue alignment work with frameworx: eTOM & SID & API Data Model | TM Forum members | yes | Huawei |
6.12. OLD 17.5 Workstream 12: ODES / DSRA / DPRA Alignment for the API program
Workstream Leader: Andreas Polz
| 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 |
12.1 | Technical mapping of solutions |
|
|
|
|
|
|
| |
| 12.2 | Data / Machine intelligence | Data / Machine intelligence – what APIs are required to support a data hub & machine intelligence (algorithm aa S, Data aa Service?) |
6.13. OLD 17.5 Workstream 13: Open MicroServices and APIs
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 |
13.1 | Open MicroServices | TRnnn | FAQ , Templates, Specifications and Cloud Platform based implementations on proposed MicroService and API architectures - First deliverable is a TR prior to Lisbon Pierre Gauthier, Nicoleta Stoica |
|
|
|
|
| |
| 13.2 | ONAP / Open API architecture | TRnnn | Technical paper exploring the technical architecture requirements to support an ONAP service enablement |
| R18 Workstream | Deliverables | Biz Challenge Question |
| 6.01: API Design Guidelines | DG4.0 - support for messaging & streaming New swagger template - Tie in the Tosca service definition with our catalogue management APIs | How do we create industry leading and technologically leading APIs that ensure capability, connectivity and exposure consistency across the ecosystem? |
| 6.02: API Processes & Governance | Need to tie up the technical architecture with stronger governance - all deliverables - 25% have no postman - clear plan & priority to complete existing and clarity of requirements for new ones. | 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? |
| 6.03: Road mapped APIs | Priority APIs from API roadmap - Clear plans & delivery of all the each step & product ownership to execute on full deliverable set | How do we ensure that the TM Forum Open APIs, planned to be developed in the API roadmap, are brought to full implementation; spec, CP, SID mapping, swagger, RI & CTK? |
| 6.04: Open API components - TR: what is an API component suite - Network as a Service (fka End-to-End NFV Management APIs) - IoT - Customer Management | TRnnn - API Component Suite concept & principal What is a CP for a conformance suite TR: NaaS component suite TR: IoT TR: CM | How do we build up TM Forum Open API suites, based on use case and requirements analysis, to support specific industry challenges? |
| 6.05: API/SID mapping Task Force | Existing mappings continue White Paper: New overall document - the generalities of how mapped - eg 15 pages for ALL the APIs. | 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? |
| 6.06: Finalize Part Completed APIs (API Spec + CP + API/SID mapping) | Outstanding items & priority as set by 6.02 - Complete the API table for existing APIs | How do we ensure that the TM Forum Open APIs, developed by a wide collaboration community, are brought to full implementation; spec, CP, SID mapping, swagger, RI & CTK? |
| 6.07: API Tooling and Automation Support | Update to support DG3.0 | How do we create a low friction and repeatable way for our collaboration community to create consistent and low effort swagger files, RI & CTK? |
| 6.08: SDO Collaborations - MEF support - Finalize Part Completed APIs (CTK) - ONAP TMF API Technical Architecture - OSM, … - ETSI, … | Apache version of MEF API New APIs for MEF support - eg trouble ticket TR ONAP TMF API Technical Architecture | How do we collaborate with other SDOs build up TM Forum Open API suites to support specific industry challenges? |
| 6.09: Catalog Management | (NaLy) | How do I, as service provider or vendor partner utilize enterprise catalogs to enable product offer creation in an open, efficient and easily understood manner. |
| 6.10: Crowd-Sourced APIs | Clear plans & delivery of all the crowd source phases & review of each step & product ownership to execute on full deliverable set | How do we ensure that the TM Forum Open APIs, developed by a crowd sourced community, are brought to full implementation; spec, CP, SID mapping, swagger, RI & CTK? |
| 6.11: API map | ? | How do we create a short, medium and long term view of how we address the demands and priorities for developing the TM Forum Open APIs? |
| 6.12: Open MicroServices and APIs | Technical recommendation on how to best use Open APIs within the context of a microservices architecture - how to use the APIs to front the microservices architecture | How do we create industry leading and technologically leading APIs that have design patterns that are optimised for the cloud based ecosystem? |
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 2017. 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:
240 Headquarters Plaza
East Tower – 10th Floor
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org