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 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)
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).
Inventory Management Systems (IMS)
Let’s start with Inventory Management Systems (IMS) because 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. 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 connectivity is important to IMS, they are more likely to have geographic and schematic / topology views of the network
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 (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):
- Product Inventory
- Service Inventory
- Resource Inventory
- 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.