Open APIs

TMF635 data model incompatibilities

  • 1.  TMF635 data model incompatibilities

    TM Forum Member
    Posted 13 days ago
    Hello colleagues,

    I am still in the process of mapping our companies data model (Billing Revenue and Innovation Management aka "BRIM") to the data model of the TMF API. And I am still facing what I assume to be incompatibilities between the data models, provided my understanding is correct.
    The following graphic describes the data model we use as I understand it.
    Data model currently in use by us

    The Consumption Item descibes the consumption of a service like a phone call. The properties contain all data characterizing the service consumption. This includes references to parties like the business partner and so on. A consumption item can only have the status "raw", "raw excepted", "unrated", "unrated excepted" and "rated".

    The Billable Item descibes an amount that is charged to a certain contract account (which in turn belongs to a customer). A billable Item can result from one consumption item or one rating item or several rating items - depending on the setup. Its status can vary between "raw", "raw excepted", "billable", "billable excepted", "billed" and "invoiced".

    A rating item describes an aggregation of usually several Consumption Items for the sake of data reduction. Such an aggregation must be supported by the business logic of course. Rating items do not necessarily have to be persisted on the database. They can be records only created as an intermediate object.

    The fundamental differences between the BRIM data model and the TMF data model are from my perspective:

    • In BRIM each class of a consumption item can have its own individual set of characteristics, by which the service usage is described. These characteristics are per se independent from the characteristics in the corresponding Billable Items.
    • In BRIM Billable Items (which contain the rated amount and are close to the RatedProductUsage Ressource) contain a set of characteristics as well. The set of characteristics describing the billable item varies from billable item class to billable item class. TMF seems to assume that RatedProductUsage sub ressources do not have characteristics of their own.
    • Several consumption items can be aggregated to one rating item, which then contains the sum of the service usage represented by the associated consumption items. This effectively allows to form an n:m relationship between consumption items and billable items. The TMF data model seems to assume a 1:n relationship between the Usage ressource and the RatedProductUsage sub ressource. 
    I have tried to do a mapping between both worlds ion the following way:

    Mapping between BRIM and TMF data models


    This attempt relies on a few assumptions, however:

    1. There needs to be an extension of the RatedProductItem sub ressource, as we need to attach custom characteristics to each of them, depending on the billable item class used.
    2. We need to have a super type of a usage ressource representing the aggregate. This aggregate, however, will be the one being extended with the RatedProductUsage sub ressources and will thus receive the status rated, while the actual consumption items equivalents (which are the sub types of the aggregates) will remain without these sub ressources. As a result the consumption items won't be able to change their status to "rated", as this status seems to imply the existence of a RatedProductUsage sub ressource.
    We are missing some equivalent objects in the TMF data model as sketched below:

    Missing objects

    1. There is no equivalent to the aggregate that I can identify as such. It would have to have characteristics just as the usage does or something equivalent.
    2. The RatedProductUsage is missing characteristics of its own.
    I am hoping for a basic misunderstanding on my side, which prevents me from integrating both data models with each other. Can anyone think of a possible solution to the problems or parts of them? Is the approach we are thinking about possible? Are we  heading into the right direction with it?

    Thanks a lot for reading so far and for your thougts.

    Best

    Carsten Zimmermann

    ------------------------------
    Carsten Zimmermann
    Deutsche Telekom AG
    ------------------------------