Open APIs

 View Only

  • 1.  API development

    TM Forum Member
    Posted Apr 17, 2017 15:12
    If we create an API today in one place - it will be different in another place, and definitely different a year from now. How will the open API's follow the development of the services they are connecting to?

    ------------------------------
    Kaj Jonasson
    Applied BSS
    ------------------------------


  • 2.  RE: API development

    TM Forum Member
    Posted Jun 07, 2017 12:26
    Hi Kai
    the APIs created and crowd sourced inside the Forum are intended to be service agnostic.  we are also committing to no more than 2 major updates in any one year. 

    we have created a governance process published in fx 16.5 and there will be further enhancements to the Fx 17 version. 

    you can view the latest published version here:
    GB996 API Governance Practice R16.5.1 - TM Forum

    thanks

    ------------------------------
    Joann O'Brien
    TM Forum
    ------------------------------

    Original Message


  • 3.  RE: API development

    Posted Oct 11, 2017 19:56
    My personal recommendation would be to hide the TMF Open APIs behind a more consumer focused set of experience APIs. I'm pretty concerned about the idea that major releases could come twice per year - is that going to include version updates? That a very high rate of change for underlying APIs which are already heavyweight...

    Also, there are some gaps in the way the current APIs are modeled. Trying to shoe-horn in SID like resource constructs has led to some significant bloat and burden of understanding. At the moment the APIs are very bottom up and therefore not fit for direct use by channels. 

    You need to provide a layer of tailored abstraction which insulates the client from underlying changes and also provides a more consumer focused experience. 

    IMHO

    ------------------------------
    Craig Bayley
    MuleSoft
    ------------------------------

    Original Message


  • 4.  RE: API development

    TM Forum Member
    Posted Jan 23, 2018 11:11
    Hi,

    My points in reply:
    • "to hide the TMF Open APIs behind a more consumer focused set of experience APIs"
      Yes, I agree to the idea of consumer-focused APIs. I think it was Gartner that first proposed the bi-model, or pace-layered-architecture view of telco - separating "Systems of Experience" (web portals, mobile-apps etc) from "Systems of Record" (CRM, Billing, Fulfillment, Assurance etc). The latter is characterized by highly process-based, heavily regulated interactions (SOx, PCI, GDPR, DPA) with more traditional, monolithic systems while the former is characterized by agile, sprint-based development, CI/CD processes, A-B testing etc.
      Imagine a holographic avatar engaging you in a conversation about your mobile use (natural-language processing, AI/ML algorithms, holograms, 3D-modelling...) - this is the land of consumer-focused, channel-specific, use-case driven agile software. At the end of this you've figured out a recommended purchase and the Avatar asks you if you want to buy it. You say/click/gesture "yes" - and that invokes the TMF Open-API for Create.ProductOrder(ProductOffering[]) - and off into the highly regulated/process-oriented world of purchase and fulfillment.
    • "concerned about the idea that major releases could come twice per year"
      That is only to say that the API programme works to two 'significant' (to avoid the over-loaded term: major) release cycles in a year. It is not to say that we aim to make a major (breaking change) to any API. All API work is demand driven. They only change when there is new demand to do so, and we try very hard not to break them through backwards incompatibility. Some APIs have been untouched since 2014.
    • "Trying to shoe-horn in SID like resource constructs has led to some significant bloat and burden of understanding"
      While I don't disagree, I would say:
      • Each TMF Open-API has its own API data model. This is derived from relevant SID entities but does not make use of all attributes/relationships if not relevant to the API interaction. SID is only the conceptual data-model in this sense.
      • "burden of understanding": Yes - but the underlying business is complex :-). Picking ProductOfferings from a ProductCatalog, each of which may carry discounts, be paid for through vouchers and other payment methods - either one-off or subscription etc. While the APIs purpose is to abstract this complexity, you can only go so far. A "bloat" eludes to "unnecessary" - and I haven't yet seen an attribute or relationship built into an API that is unnecessary to everyone.
    • "need to provide a layer of tailored abstraction which insulates the client from underlying changes"
      There is a need for both, but I would start with the systems-of-reference, abstracting high-level domains like parties (suppliers/partners/customers: consumer, enterprise, SME/SOHO/Corporate/Multi-National), products (offerings in a catalog that could come from fixed, mobile, TV, broadband or fridges) etc - and that is where the TMF Open-APIs are focused. This gives a stable abstraction for the systems-of-experience to build on.


    ------------------------------
    Stephen Harrop
    Principal Integration Architect
    Vodafone Group
    ------------------------------

    Original Message