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

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

  • Inventory Management Systems 
  • Asset Management Systems and
  • Configuration Management Databases (CMDB)
  • We might even discuss Virtual Infrastructure (VIM) and Resource Managers as well as Config Managers (different from CMDB) too

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

Let’s start with Inventory Management Systems (IMS) because IMHO, these are the tools that were traditionally responsible for managing service-provider networks. These are the tools typically used by network planners, network engineers, capacity planners and other back-office operational staff.  As mentioned in the link above, these tools 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.
  • LNI (Logical Network Inventory) – The set of objects that are formed using physical infrastructure (and possibly associations to other logical objects). This could include circuits, VLANs, and other overlay network topologies as well as 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
  • More importantly, IMS often have network project planning tools to allow design teams to plan for network augmentation
  • Since connectivity is important to IMS, they are more likely to have geographic and schematic / topology views of the network

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 LNI-related data. 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) 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.

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 easier in an IMS than a CMDB.

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

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

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

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “The differences between Inventory, Asset and Config Management in an OSS

  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!

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.