The differences between Inventory, Asset and Config Management in an OSS

We recently discussed the differences between PNI (Physical Network Inventory) and LNI (Logical Network Inventory) solutions that appear as part of many OSS (Operational Support System) stacks. 

As promised, today we’ll talk about the subtle differences between:

  • Network Inventory Management Systems 
  • Asset Management Systems and
  • Configuration Management Databases (CMDB)

We even discuss:

  • Virtual Infrastructure (VIM) and Resource Managers
  • Config Managers (different from CMDB)
  • TM Forum’s four main styles of inventory (Product, Service, Resource, Entity)
  • Where these solutions fit within a typical Network Lifecycle Management (NLM) chain

Inventory vs Asset vs CMDB

To be honest, the diagram above doesn’t show adequate overlap. Each of these systems has a slightly different purpose, usually for a slightly different set of personas. However, they all play a part in managing the resources that make up an organisation’s Active Network (the network segment dedicated to carrying customer traffic, as opposed to internal corporate traffic). Each one acts as a primary source of truth for the current state of the network and asset inventory. Many other operational processes and tools are dependent on each one of the following solutions:


Network Inventory Management Systems (IMS)

Let’s start with Network Inventory Management Systems (IMS) because these are the tools that were traditionally responsible for managing service-provider networks. These network resource management tools are typically used by network planners, network engineers, capacity planners and other back-office operational staff.  As mentioned in the link above, these network inventory solutions can be further broken down into:

  • PNI (Physical Network Inventory) – The physical devices like switches, routers, firewalls as well as the outside plant (OSP) like cables, joints, etc. Generally only used by operators with large, wide-spread networks of physical assets, especially outside plant. This also includes point-to-point radio network links like satellite, fixed wireless, radio/TV re-broadcast, etc.
  • LNI (Logical Network Inventory) – The set of objects that utilise the physical infrastructure (and possibly associations to other logical objects). This could include logical circuits, Virtual Private Networks (VPNs), and other overlay network topologies. It also includes the management of attributes like bandwidth, protocols and other network functionality

These tools tend to focus on the key physical/logical/virtual resources that comprise an operator’s active network (AN). However, they often also support functionality that crosses into other domains such as asset and config management.

The main differences between Inventory and Asset Management systems is that:

  • Inventory tends to have the concept of connectivity (eg cables, patch panels, circuits, networks, topologies), which asset management rarely cares about
  • Inventory tends to align customer services / circuits to devices to help identify utilisation, available capacity and service impact analysis, which asset management rarely cares about
  • This includes service hierarchies, multiplexing and networks / meshes, which is great for root-cause analysis
  • More importantly, IMS often have network project planning tools to allow design teams to plan for network augmentation and adds/moves/changes
  • Since asset locations and connectivity are important to IMS, they are more likely to have geographic and schematic / topology views of the network that show the physical location of devices and connectivity

Asset Management Systems

Asset Management Systems (AMS), as the name implies, have a more “financial” purpose; where assets are objects of intrinsic financial value to an organisation. AMS tools tend to be used by the accounting and asset management teams. Asset / device life-cycle management such as the use-cases described below are sometimes performed by operational teams.

They’re used to track current value (purchase price minus depreciation), warranties, spares management, life-cycles / refresh / end-of-life of assets and their contracts, as well as reactive and predictive maintenance and reliability management. AMS will tend to store information about most of the Active Network Physical devices. This means they will have records for the same devices as PNI, but often with different information / attributes.

They won’t tend to store logical network data, or connectivity or service mappings. However, AMS will often keep information about assets in addition to Active Network devices. This could include software licenses and more.

AMS will tend to consider unique network devices down to the level of serial numbers so that they can be tracked through a unique device’s life-cycle from order to warehouse to in-service to scrapping. IMS tools can store device serial numbers but tend to track devices by function (eg Router-0001 connects SiteA to SiteB). If the device in that function (eg Router-0001) fails, then a new one is inserted with the same same.

Some providers don’t even manage financial assets to a device level. They clump costs by site or project, with no relationships to asset details or the asset management use-cases described above.

Configuration Management Databases (CMDB)

Configuration Management Databases (CMDB) is more of an IT Service Management (ITSM) terminology. Like many IT concepts, ITSM has been increasingly used in parts of service provider networks. CMDBs are a database of Configuration Items (CIs), where CIs can be logical or physical entities. CIs may (or may not) be physical devices (PNI) or logical resource entities (LNI) and may (or may not) represent tangible values (assets). The main purpose of CIs is to store information about IT services that will allow other ITSM processes, such as Incident, Problem and Change Management, to be performed efficiently.

Generally, CMDB will not tend to store connectivity, especially end-to-end connectivity for customers that we otherwise know as services (different from ITSM’s definition of services).

Not only is there functional overlap between these systems, there’s often also terminology overlap and/or misalignments. Different vendors have different levels of functionality and support alternate use-cases, so the areas of overlap differ between organisations.

CMDB tend to have great flexibility to create associations (eg parent, child, related to, etc), that can establish the connectivity and hierarchies of an IMS. However, they tend to require significant effort to establish and maintain rather than having pre-established relationships like IMS do.

An example might be a cable that connects from port 1 on device A to port 5 on device B, but then gets re-patched to port 8 – this scenario tends to be far easier in an IMS than a CMDB.

This also means that root-cause (RCA) and service-impact (SIA) analysis can possibly be performed in a CMDB, but are usually better performed by an IMS. 

Oh, and I also promised to mention VIMs and Config Managers:

Virtual Infrastructure Managers (VIM)

Virtual Infrastructure Managers (VIM) are responsible for managing the virtual resources made available by physical infrastructure like compute, storage and network devices. In some cases, VIMs generate virtual network devices (VNFs) or virtual machines (VMs) that could look almost identical to any other device stored in LNI, PNI, AMS and/or CMDB. In fact, instances of these VNFs and VMs may even appear in those systems.

Config Management

Config Management (as opposed to, but also potentially overlapping with, CMDB), is all about managing the configurations of devices in the network (often active network and corporate network). Each device, such as a router, has a configuration that tells the hardware how to function, where to route traffic, which packets to prioritise, where to send management logs (to the OSS), etc. Being able to monitor and manage these configurations centrally and consistently is the purpose for Config Managers.

These are mostly used by network engineers to set policies and golden-configs (ie the config templates that all devices of that type must adhere to consistently). For example, you may have hundreds/thousands of devices in your network and want to re-point all management traffic to a new server as part of an OSS upgrade. Rather than configuring each device separately and manually, you can use the config management tool to push config changes out to the network.

TM Forum Inventory Models

The TM Forum recognises four main types of inventory (well, they have a bunch of others too but we’ll stay focused on the four):

  1. Product Inventory
  2. Service Inventory
  3. Resource Inventory
  4. Entity Inventory

Product Inventory – (captured as TMF637 in the Open API specs and Product ABE of SID). A product represents an instance of a product offering for a subscriber. Its inventory captures details such as the place the product is in use, its configuration characteristics (eg phone numbers, IP addresses, etc). It also tracks the services and/or resources that the product is comprised of. A product is realised as one or more services and/or resources.

Service Inventory – (TMF638 and Service ABE). Services may (or may not) be visible / usable by customers. The service inventory consists of:

  • Customer facing service (CFS) instances, and their attributes
  • Resource facing service (RFS) instances, and their attributes
  • Mappings between CFS and RFS, other services, resources and
  • Other service-related attributes

Resource Inventory – (TMF639 and Resource ABE). Resources (eg servers, routers, cables, applications, etc) are used to implement services and products. Resource Inventory Management provides a database of objects (and their attributes like serial numbers, specifications, etc) that are important to monitor and manage the network (and associated infrastructure) as well as service fulfilment. They may also be used for managing spare parts / warehousing to ensure resource management across entire life-cycles (from ordering to install to repair to decommissioning). They serve many other purposes and use-cases as well, from capacity management, revenue leakage, diagnose & repair, availability, service qualification and much more.

Entity Inventory – (TMF703). Entity Inventory is more of a catch-all concept, allowing for the capture of other things that aren’t addressed by Product, Service or Resource Inventories.

Leave us a message to describe how your organisation use these (and other) tools.

How they assist with Network Lifecycle Management (NLM)

Ultimately, all of these tools play an important role in the lifecycle of a network and the components the network is comprised of. Depending on the particular off-the-shelf product, they will all contribute to some or all of the following steps in a typical NLM chain:


Network Inventory solutions typically cover all 5 stages of the lifecycle above, but aren’t always strong in the “Survey and Build” phase because operators tend to rely on workforce management, contract management and/or project management tools for this.

CMDBs typically cover the Asset Onboarding and O&M stages of the lifecycle. They’re often paired up with ITSM solutions that manage the O&M phase, which tends to make them stronger in O&M than most network inventory solutions.

Asset Management solutions are typically only used for a sub-set of Planning (BoQ preparation), Asset Onboarding (database updates and vendor & warranty management) and O&M (Performance tuning, audits, upgrade and decommissioning).

However, we should re-iterate that each vendor / make / model of these categories of solutions has different functionality, strengths and weaknesses. It’s quite possible that your solution/s of choice cover a different range of functionality coverage than the “typical” solutions we’ve described above.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

4 Responses

  1. Thanks Ryan for this nice article. Systems also espouse organizational boundaries and purchasing authorities. I believe that the various types of systems that you outline correspond to the CTO/CFO/CIO realms. I remember a past TMF project that tried to bridge the gap between CTO and CFO, and which failed, not on technical grounds, but because it was just too difficult to make both types of organisations agree on a single system.

  2. That’s a really savvy observation Roland!
    I’d broadly categorised by different persona types, but you’ve more succinctly aligned persona groupings by saying CTO (Inventory Management), CFO (Asset Management) and CIO (CMDB). Brilliant!!
    That’s really interesting about the TM Forum project. To be honest, it doesn’t surprise me that organisational barriers were the problem rather than technical challenges. There would be entire internal empires at stake!!
    I guess every organisation has different org structures, roles/responsibilities and politics so the lines of demarcation would vary from organisation to organisation!

  3. Thanks Ryan

    When dealing with B2B BSS/OSS, can you further describe what you would expect to see in the BSS Asset please (and what you would not 🙂 )?

    Ideally I would have thought you need to be careful not to store something that is mastered in the service layer, but in a fluid and multi-year transformation, it is tempting to assetise service attributes so that agents can access said information through the BSS layer that they might not (yet) otherwise have access to.

  4. Great post with unique information. This blog will be really helpful for me to develop my skills in the right way. Thanks for sharing, keep updated with your blogs.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.