TM Forum Community

Expand all | Collapse all

Modelling a future proof OSS Physical Inventory

  • 1.  Modelling a future proof OSS Physical Inventory

    TM Forum Member
    Posted Dec 28, 2018 16:47

    i'm working on a large OSS Transformation to provide future proof capabilities and service. We're migration the legacy physical inventory to a brand new inventory ( Physical equipment hierarchy, cableing, Outside Plant Infrastructure, geographic places, etc).

    Which's in your opioning best model for the physical resources hirarchies? Do you know best practices, standards can help me?

    Thanks in advance

    Stefano Gufi

  • 2.  RE: Modelling a future proof OSS Physical Inventory

    TM Forum Member
    Posted Dec 31, 2018 11:49

    My company recently created a new inventory database to cover both physical and virtual resources (but not external plant). The basis of the data structure was the TM Forum Information Model (often known as SID). The guidance documents explain that an information model must be adapted to become a suitable data model for a particular ​business use and that is indeed what our designers did in our case.

    My current work in the ODA project of the Forum is now considering how such inventories can be populated; a new resource instance will be instantiation of resource specification held in a resource catalogue and our 'on-boarding' work is looking at how that catalogue can be populated with approved vendor offerings customised to the needs of the service provider.

    Paul Jordan
    BT Group plc

  • 3.  RE: Modelling a future proof OSS Physical Inventory

    TM Forum Member
    Posted Dec 31, 2018 11:50
       We are now working on a Big Transformation Project and already succeed making part of it Golive. Our strategy is that we separate the network Domains, like ETN,DSL,OTN etc. And before migration, we actually ask target Inventory to provide a standard model staging table so lots of legacy system have enough time and understanding about it so they can map to new model gradually.
      Target staging table includes site, device, cabling and services etc. And for these devices which cross the network, e.g end points is not migrated yet as ETN is migrating while DSL is still pending, then we model it as a place holder. Of course, from service perspective, place holder has covered it as well. in this way later on DSL is migrated, then it can be integrated together.
       This is basically our way it is partially already worked, hope it can help.

    tony he
    Whale Cloud Technology Co., Ltd

  • 4.  RE: Modelling a future proof OSS Physical Inventory

    Posted Dec 31, 2018 11:50
    "Futureproof" is an interesting term. A lot depends on what you mean by it.

    In reality, there's no such thing.

    Architectures and technologies evolve, become deprecated, get replaced by newer iterations or simply better versions. Possibly more significant than that, vendors develop new products and new versions of products, which have different platform requirements, and stop supporting old ones. Operational skills evolve and older skills become scarce (e.g. COBOL). When you implement a commercial product, its future is limited from the day you install it. Bear in mind a lot of platforms have artificial lifetime limitations based on licences, support contracts, and commercial costs.

    Obviously there are things you can do to mitigate this, but there are no magic bullets. The only approach that really works is a long-term plan that understands the status of the platform and which includes plans (and budget) for platform changes, upgrades and migrations. That may include significant "fork-lift" upgrades of parts of the platform at some point in the future. If you have done it right, that should be at least 5-10 years away.

    The absolute worst thing you can do with any platform is to assume that what you have is "futureproof", and to not plan for upgrades and changes. In that way, any platform will "rot" and is likely to become an operational burden. It is also more likely to require a complete change out at some point.

    This may all seem obvious but, in my experience, actually doing this is rare, because businesses don't understand the life-cycle of IT and just see it as an unnecessary cost to the business.

    Other things I would recommend you should consider: look at "Cloud" technologies. By this I'm talking about things like Openstack, Kubernetes, and microservices. These are designed to support development of flexible services on low-cost commodity hardware. You can either deploy the hardware stack yourself, use an external private or public cloud provider or, if you've done it well, use a mixture of these as the needs of the business dictate. This gives you massive flexibility in terms of platform suppliers as you can, relatively easily, move services between platforms (whether that is hardware vendors, or commercial cloud providers).

    The bad news is, if you are looking at commercial solutions, there aren't many which will run natively in such an environment, although there's a great many that will.

    Note that such an environment will have a design and operational requirement which is, IMO, best served by building an small in-house team of experts who are responsible for the design, and the ongoing strategy including platform upgrades and changes. This fits in with my statements above. IMO this really can't easily be outsourced as almost all of the places you could outsource this sort of thing really aren't very good at it in the long term (I say this having worked with and for such companies).

    The big advantage of your own in-house team is it gives you the opportunity to use more Open Source in your stack. This has the advantage that the support is down to you.

    This may sound like a disadvantage, but it really isn't: if you want to continue supporting and patching an older version of an application and have the in-house skills, you can choose to do so and it's not really going to cost you anything; if you want to trial the latest version of something, you can do so without having to purchase or negotiate licences, and without having salesmen hassling you; if something isn't quite working the way you want, you can make changes yourself (or sponsor a change) and it will happen far more quickly and cost far less than trying to get changes made to a commercial system.

    And, as a final note, the biggest thing you can do to extend the life of your IT architecture: do not sign any Enterprise wide IT deals.

    The commercial people love these because they look good on their CVs and often drive their bonuses, but the reality is these are harmful to the business: they lock you into a vendor who can never 100% meet your IT needs (if you are lucky they might meet 30-40%) and the rest gets done badly if at all. The best approach is to have a skilled and knowledgeable technical team who can chose from multiple suppliers and who can mix and match technologies and vendors as they develop and evolve the architecture.

    Best of luck,


    Keith Milner
    Superlative Solutions Ltd.

  • 5.  RE: Modelling a future proof OSS Physical Inventory

    TM Forum Member
    Posted Jan 01, 2019 18:49
    "Futureproof" these days should consider 5G - in particular 5G network slicing.

    I beleive the customer facing aspects of 5G network slicing are ridiculously overestimated, whereas the resource facing aspects are ridiculously underestimated.

    My recommendation would be to consider the impact of 5G network slicing to the resource inventory.

    Lothar Reith

    Lothar Reith
    Detecon International GmbH

  • 6.  RE: Modelling a future proof OSS Physical Inventory

    Posted Jan 03, 2019 09:54
    Concur on last para absolutely

    Peter Curnow-Ford

  • 7.  RE: Modelling a future proof OSS Physical Inventory

    Posted Jan 03, 2019 17:09
    I am also looking for a model that can be used for facilities management and infrastructure to support lifecycle management of access services over xDSL/GFast, xPON and fiber point-to-point.  The model should include equipment (access and CPE), facilities (L1 Links, L2 and L3 flows) and services (e.g. voice, video, data, MEF).  I know there was some modeling done that was exposed as part of the MTOSI effort, but I can't seem to find any domain specific models, though I'm told they exist either at TM Forum, ONF, MEF and/or all.

    If anyone could help, I'd appreciate it.


    Phil Fine
    National Information Solutions Cooperative, Inc.
    Product Manager

  • 8.  RE: Modelling a future proof OSS Physical Inventory

    TM Forum Member
    Posted Mar 08, 2019 04:45
    I had implemented one. It was not for the network resources of the operator, but resources that is transferred from central inventory to dealer and shops and sold to customers there.

    We had used Physical Resource Spec (Composite), Characteristics, Party-Role domain for the organizations, Place to keep the places of the resources.

    If you adhere to the abstractions of SID, do not over-simplify it, you won't need to modify your model, but extend it easily.

    For your abstractions to work you need to support inheritance of SID entities, when persisting them. Use an ORM and DB that both supports entity inheritance.

    I would like to answer if you have any specific questions.

    evren okcu
    Ericsson Inc.