Page tree
Skip to end of metadata
Go to start of metadata

* indicates that this field is required

Project Name*Open API Program
IPR Mode*

RAND

Explanations of each mode is available at http://www.tmforum.org/IPRPolicy/11525/home.html

Project Start Date*July 2018
Project End Date*February 2019
Type of Project*Development Project
Strategic ProgramAgile Business & IT
Previous Project CharterOpen API Program Charter (R18.0) - A Core Project Area Charter
Project Workspace LinkAPI Project Home
Project Sponsor*
Project Team Lead*
TM Forum Staff Support

 

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 (R18.5) - DRAFT


 

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 NameINPUT FROM / OUTPUT TO / JOINT WITHCOMMENTS (describe nature of Input / Output / Joint)API ContactOther Project Contact
API-Apache 2.0OAPI specifications team approved and published to the API-Apache 2.0 project where the Swagger will be constructed 
API-Apache 2.0IOnce 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 CentricityI & OEnsure consistentcy between the Customer Care type Component Suites and the Customer Centricity program 
Security & PrivacyI & OEnsure 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 EcosystemsI & OThe IoE API Component suite should evaluate previous scenarios from the IoE program for valid use cases. 
DMMI & OA review of the technology area of the DMM is required to ensure that it meets the needs of the ODA & API programs. 
AI & MLI &OReview the advancements by the AI Program for implications to the API program 
FrameworxJointAPI / SID mapping.
Open Digital ArchJoint

ONAP product suite

NaaS product suite

 
Smart CityI & OMerging Open Digital APIs with FiWARE APIs - API specification workPierre 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.

RoleName*Company* Confluence “@” mentionComments
Project Co-Team LeadAndreas PolzInfonova 
Project Co-Team LeadSteve HarropVodaphoneStephen Harrop 
MentorPierre GauthierTM Forum 
Sponsor*Laurent LeboucherOrange 
Subject Matter ExpertPierre GauthierTM Forum 
StaffGeorge GlassTM 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 GauthierStephen Harrop

The API design guidelines capture the REST base patterns to be deployed across all TM Forum Open APIs.  Consistent application of these guidelines is key to the successful development and application of a consistent suite of APIs.  This includes also the extension capabilties to the APIs. 
Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.01.1API Design Guidelines 3.1 - The next "DG3.0 compliance stage" developing beyond polymorphic support

Confluence Guidance notes & Swagger generator tool updates

<Punch list: No formal R18.5 publishable item>

  • DG3.1 - minimum spec for swagger file
  • Support polymorphism
  • Event Support
    • Event support (minor) - notification description in the swagger of the API - needs a convention
  • Entity RefofValue
    • Ref or Value: more explicit
  • Characteristic Value
  • <Validation>
  • <Swagger Template>
  • Version support - DG change to put the major version (mandatory) & minor version (optionally) in the URL and to show this in the examples
     

Confluence has been updated & the generation tool is being updated.

6.01.2API Design Guidelines 4.0

TMF630

<Punch list: => R19.0>

  • Specific Data model supports (iTIL Firewalls)
  • Open API component suite principals & patterns
  • The notion of a schema registry
  • Component Suite concept & principal (initially developed stand-alone, then merge into DG)
  • Polymorphic pattern - improve explanation, more precise, more explicit examples
  • Separation of concern - definition and JSON-schema (imported)
  • Events (schema) (bigger & more disruptive work)
  • Support for reactive based design - Evolution of Transport / Protocols (currently use http - may need more modern messaging protocol with lower latency)
  • OS migration - Support for swagger 3.0
    • Moving to swagger 3.0?
    • Swagger template
    • Including events & notifications
    • Decoupling JSON schema from swagger (DGx.0)
      • In this mode, you import the data model, essentially there are now two files, rather than one
  • Component Suite Concept & Principals (that will become absorbed into DG4.0)
     

 no progress

6.01.3Hypermedia Support

<Punch list: No formal R18.5 publishable item>

  • Focus has been on polymorphic support & extendability, however true hypermedia support is still to be widely adopted
  • Hypermedia - implementing DG3.0 hypermedia - additive - needs a dedicated effort to start & lead the way. The design of Trouble Ticket has already been updated (by Nicoleta) to address this.

  • What are the "five key points" we need to address & validate?

  • Address in component suites?

      

 

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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.02.1Tiger Team for urgent updates<Punch list: => R19.0>
  • Raise a Tiger Team to address back-log of APIs yet to be migrated from RAND license mode to Apache 2.0 license mode
  • Possibly use the same team to drive the Open API table to be correctly populated and correctly tie to the API catalogue
  • Maybe have the Specs/CF in a RAND GitHub while the Apache/Postman files are in the Apache 2.0 GitHub.
  • Open API table loading - Stephen Harrop
    • Automation of publishing and updates, UML files in GitHub, etc.?
  • API backlog to bring pre DG3.0 to DG3.1 - LEAD - team leads
  • API backlog to bring DG3.0 API to DG3.1 - LEAD - team leads
     

 new focus is the NaaS 7.

6.02.2Bringing all APIs to DG3.1 minimum compliance<Punch list: => R19.0>
  • First priority is to get ALL APIs to DG3.0 compliance
     

  new focus is the NaaS 7.

6.02.3Manage JIRA<Punch list: No formal R18.5 publishable item>Manage JIRA backlog, monitor JIRA per API and as part of API reviews, systemetise JIRA views into API review tables      
6.02.4Auto generate the API catalog from Jira<Punch list: No formal R18.5 publishable item>Advance the industrialization of the use of JIRA to a point that we are confident to auto generate the API catalog from Jira      

 

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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.03.1General goal

API Catalogue

<Punch list: No formal R18.5 publishable item>

Priority APIs from API roadmap - Clear plans & delivery of all the each step & product ownership to execute on full deliverable set      
6.03.2Policy API

TMF693

<Punch list: => R19.0>

  • Need to be able to create & retrieve policies
  Design/SID mapping complete  MEF has an interest in Policy (from Fred/Verizon)
6.03.3Product Catalogue API & Rules

TMF620

<Punch list: stretch for R18.5>

  • Product Offering Relationship
    • This is already in SID - all agree & support.
  • Product Offering Characteristics
  • Channel on Category
  • Channel for Attachment
  • Catalogue & policy rules
  Design/SID mapping completeCompleted Spec/Swagger, Conformance ProfileR18.5 release on 3-December
6.03.4Service test to Test API

TMF653

<Punch list: => R19.0>

  • Make DG3.0 and service test becomes a component of test
JAD Catalyst APIs
     

 Frank Massoudian presented at TAW, Dallas and is working with the team to progress.

6.03.6PM/Usage mgt API

TMF628 / TMF635

<Punch list: => R19.0>

      
6.03.7Distributed Ledger API

TMF695

<Punch list: stretch for R18.5>

      

Pieter Janse van Rensburg 

Philip Stander

AP-1040 - Getting issue details... STATUS

6.03.8Customer Risk API

TMF696

<Punch list: stretch for R18.5>

  • 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.
    

Moshe Zolotov (Amdocs)

Moshe is working on this on a "best efforts" basis with no guarrantee for R18.5
6.03.9Stock Management API

TMF687

<Punch list: stretch for R18.5>

     

Vodafone has an AP-1059 - Getting issue details... STATUS contribution to this

6.03.10Party Management

TMF632

<Punch list: stretch for R18.5>

     

Will present work to date on  

 

6.04: Open API components

Workstream Leader: Pierre GauthierStephen HarropJoann O'Brien

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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.04.1What 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
 Refine based on R18 experience<Punch list: No formal R18.5 publishable item>
  • Definition
    • Need to do a much better job of explaining about what it is and there is a lot of misunderstanding
  • Conformance
  • Concepts & Principals via DGx
    • Does not standardise work flows
    • Provides functions and end-points
    • Normative means
      • if ... then
        • If you provide service definition, then you can ...
  • IoT (Axiata are interested) and Smart City (based on harvesting catalyst work)
  • Single swagger definition
      
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.2.2

TMF633-ServiceCatalog

TMF633

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.3

TMF638-ServiceInventory (Phase 2)

TMF638

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      

6.04.2.4

TMF640-Activation&Configuration

TMF640

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.5

TMF641-ServiceOrdering (Phase 2)

TMF641

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.6TMF645-ServiceQualification

TMF645

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.7TMF653-ServiceTest

TMF653

<Punch list: => Publish for R18.5>

 Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.8TMF656-ServiceProblem

TMF656

<Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.2.9TMF677-UsageConsumption

TMF677

 <Punch list: => Publish for R18.5>

Update to use schemas/model-schemas with the latest ("definitions" rather than "properties") and use latest tool chain.      
6.04.3TR908: IoT

TR908

<Punch list: => R19.0>

IoT component suite     

Axiata

6.04.5TR911: MEF product suite

TR911

<Punch list: => R19.0>

Possible future component suite     Ludovic Robert
6.04.6TR912: ONAP product suite

TR912

<Punch list: => R19.0>

Possible future component suite     Ludovic Robert

 

6.05: API/SID mapping Task Force

Workstream Leader: Cecile LudwichowskiMichel 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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.05.1  White Paper: New overall document - the generalities of how mapped - eg 15 pages for ALL the APIs.      
6.05.2API / SID assigned mappings

TMF620A
TMF621A
TMF632A
TMF633A
TMF639A
TMF645A
TMF652A
TMF654A
TMF655A
TMF657A
TMF658A
TMF663A
TMF666A
TMF668A
TMF669A
TMF671A
TMF673A
TMF674A
TMF675A
TMF677A
TMF680A
TMF681A
TMF683A
TMF684A

<Punch list: => R19.0>

Product Catalog Management, Trouble Ticket, Party, Service Catalog Management, Resource Inventory, Service Qualification, Resource Order Management, Prepaid Balance, Change, Service Quality, Loyalty, Shopping Cart, Account Management, Partnership type, Party Role, Promotion, Geographic Address Management, Geographic Site, Geographic Location, Usage consumption, Recommendation, Communication, Party Interaction, Shipment Tracking

      
 TMF633A<Punch list: => Publish for R18.5, team approved>TMF633A - Service Catalog Management SID mapping R18.5     

 

 TMF663A<Punch list: => Publish for R18.5, team approved>TMF663A - Shopping Cart SID mapping R18.5     

 

 TMF669A<Punch list: => Publish for R18.5, team approved>TMF669A - Party Role SID mapping - For R18.5 review     

 

 TMF677A<Punch list: => Publish for R18.5, team approved>TMF677A - Usage Consumption SID mapping     

 

 TMF683A<Punch list: => Publish for R18.5, team approved>TMF683A - Party Interaction SID mapping R18.5     

 

          

 

6.06: Driving API Adoption

Workstream Leader: Joann O'Brien

 

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.06.1API steering committee<Punch list: No formal R18.5 publishable item>

API steering committee

      
6.06.2CSP driven Vendor API adoption assessment<Punch list: No formal R18.5 publishable item>CSP driven Vendor API adoption assessment      
6.06.3API Conformance<Punch list: No formal R18.5 publishable item>Deploy API Conformance product      
6.06.4API Governance Assessment<Punch list: No formal R18.5 publishable item>Develop and deploy an API Governance Assessment that companies can use to help evaluation the maturity of their structures, processes and execution regarding being API driven.      
6.06.5API Developer Ambassador Community<Punch list: No formal R18.5 publishable item>Develop an API Developer Ambassador Community for TM Forum Open APIs      
6.05.6Setup a TM Forum Open API presence inside the Linux Community<Punch list: No formal R18.5 publishable item>       
6.05.7Devise and gain agreement for a TM Forum Open API Open Source Strategy<Punch list: No formal R18.5 publishable item>Develop the strategy and gain agreement with Open API sponsors and TM Forum Open Collaboration SubCommittee, and the board if required.      

 

6.07: API Tooling and Automation Support

Workstream Leader: Stephen HarropMariano 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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.07.1Update to support DG3.1<Punch list: No formal R18.5 publishable item>Update to support DG3.1      
6.07.2RI/CTK tooling improvements<Punch list: No formal R18.5 publishable item>Develop the initial RI/CTK tooling      
6.07.3Tool 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: Joann O'BrienPierre 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/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.08.1MEF 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.2ONAP 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.3OSM, …<Punch list: No formal R18.5 publishable item>Currently not actively worked, Volunteers from members welcome to help      
6.08.4ETSI, …<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 HarropAndreas 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. 

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.09.1 <Punch list: => R19.0>Reserved for new APIs crowd-sourced from members.      


6.10: Event Streaming & Messaging

Workstream Leader: Pierre Gauthier

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.10.1Event Streaming API<Punch list: => R19.0>
  • Verizon, NATO, AT&T are all interested in this
  • Relies on schema registry
  • Current lead is NATO
  • Incubating developments in API Architecture team
  • PiGa: <presented slides, may be found here: API Architecture Workstream, see "Event Streaming and Messaging"
    • Will be meeting & discussing with NATO in about 2 weeks
    • ONAP has something similar, but not generalised (names event pairs) and telematics, not business events
    • Registry based, so messages & message types may be added at run time
  • Microservice view
    • Today, using http with POST to listener
    • As the number of microservces grows, this becomes unsustainable
    • Need to decouple the microservices to an event hub or bus
  • Event taxonomy
    • Today, each event has its own JSON schema
    • Events will be extendable with the normal patterns
  • The event hub or bus can support multiple async protocols
    • http
    • AMQP (RabbitMQ)
    • MQTT (IoT)
    • Kafka
  • Messaging protocols (DG4.0)
    • multi-cast style - but it is not
    • needs evaluation / trial in the lab by early adoptors
    • It is publishing a message to a queue - a specific recipient
    • Specifies where the response should be sent to - this is different to the Event API
    • Externalise the request and the response (and the exception)
    • Can have multiple response
    • Would expect at least a positive acknowledgement response
    • Needs a messaging schema
  • Andreas Polz - We (Bearingpoint) have created a centralised event hub, in our version of the APIs.
    • Stephen Harrop - We (Vodafone) have done the same
    • PiGa: We are not deprecating the current events in each API, but we will provide both systems
      

 

6.11: RI & CTK Task Force

Workstream Leader: Stephen Harrop

 

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.11.01RI/CTK structureGitHub structureCreate RAND GitHub structures      
6.11.02CTK tooling        
6.11.02RI tooling        
6.11.03Populate CTKs        
6.11.04Populate RIs        

 

6.12: API Mapping

Workstream Leader: Joann O'Brien

 

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.12.01API MapGB992Summary paper showing all the current and planned APIs, updated periodically as API releases develop     

Author for R18.0 update: Hongxia Hao

6.12.02API functional mapping to eTOM & TAMtbaMapping 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

 

 

FIWAREexistingSharing API standards  
Eclipse/Papyrusexistinguse of Tooling  
Open NFVTentative   

10. Charter History

Version Date Comment
Current Version (v. 30) Feb 26, 2019 14:44 Derek Flexer
v. 29 Oct 25, 2018 10:30 Derek Flexer
v. 28 Oct 25, 2018 06:40 Derek Flexer
v. 27 Oct 22, 2018 09:26 Derek Flexer
v. 26 Oct 22, 2018 09:23 Derek Flexer
v. 25 Oct 22, 2018 07:56 Derek Flexer
v. 24 Oct 22, 2018 07:12 Derek Flexer
v. 23 Oct 22, 2018 07:02 Derek Flexer
v. 22 Oct 22, 2018 05:52 Derek Flexer
v. 21 Oct 09, 2018 10:03 Pieter Janse van Rensburg
v. 20 Sep 25, 2018 13:35 Stephen Harrop
v. 19 Aug 28, 2018 10:01 Stephen Harrop
v. 18 Aug 22, 2018 10:12 Stephen Harrop
v. 17 Aug 17, 2018 12:48 Derek Flexer
v. 16 Aug 17, 2018 10:19 Joann O'Brien
v. 15 Aug 17, 2018 09:37 Derek Flexer
v. 14 Aug 17, 2018 09:36 Derek Flexer
v. 13 Aug 17, 2018 09:01 Derek Flexer
v. 12 Aug 17, 2018 04:56 Joann O'Brien
v. 11 Aug 17, 2018 04:30 Joann O'Brien
v. 10 Aug 15, 2018 12:27 Joann O'Brien
v. 9 Aug 15, 2018 12:12 Joann O'Brien
v. 8 Aug 15, 2018 12:05 Joann O'Brien
v. 7 Aug 13, 2018 06:06 Derek Flexer
v. 6 Aug 13, 2018 06:01 Derek Flexer
v. 5 Jul 27, 2018 08:53 Derek Flexer
v. 4 Jul 27, 2018 08:30 Derek Flexer
v. 3 Jul 27, 2018 04:47 Derek Flexer
v. 2 Jul 11, 2018 11:19 Derek Flexer
v. 1 Jul 11, 2018 11:08 Derek Flexer

11. Role Definition & Responsibilities

 Role Descriptions & Responsibilities

Project Team Lead:

  • Ensure project is developed in line with TM Forum IPR policy
  • Encourage all participants to take an active role in the project
  • Ensure participants have a clear understanding of what they need to complete and when
  • Drive the project team for on time delivery
  • Lead the design, planning and execution validation activities
  • Identify key companies required to position for industry adoption

Mentor:

  • Aid the team to maintain focus on delivery
  • Act as a source of expertise for the team
  • Join project calls to assist with blockages
  • Seek out expert resource to help as required
  • Be a guide and link to the wider Program

Sponsor:

  • Articulate the Industry User Story
  • Act as a Champion for the team
  • Review progress at six weekly intervals to ensure relevance
  • Champion final deliverables at Nice/San Jose
  • Drive Adoption in own organization by championing deliverables as beta versions of solutions to be developed

Participant:

  • Develop collaborative solutions as in accordance with the developed charter and inline with Collaboration process
  • Participate actively in team working meetings / sessions
  • Complete tasks as agreed with the team or workstream leader

Observer:

  • Choose to observe and monitor the progress of a project team
  • Use the insights gained to share observed advancements within your organization
  • Ensure planned deliveries are aligned with product roadmap in your organization to gain maximum R&D acceleration value
  • Align training and education within your organization to gain maximum value of cost & risk reduction and future proofing your organization

Reviewer:

  • All activities of observer plus…
  • Review all outputs from team and provide quality timely feedback ensuring output aligns with business and technology requirements of your organization
  • Participate in validation activities, these may be online or face to face.
  • Monitor Collaboration Events & Activities page for all latest review activities

Subject Matter Expert:

  • Provide support and guidance to a project team in your particular area of expertise

Workstream Lead:

  • For your agreed workstream;
  • Ensure project is developed in line with TM Forum IPR policy
  • Encourage all participants to take an active role in the project
  • Ensure participants have a clear understanding of what they need to complete and when
  • Drive the project team for on time delivery
  • Lead the design, planning and execution validation activities
  • Identify key companies required to position for industry adoption

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

  • No labels