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