In order to solve asset utilization challenges, the physical inventory in the
network needs to be discovered, and compared to the inventory in planning
systems. In many organizations, there are a combination of systems with data
for different network technologies, and administrative domains. This can be
further complicated by environments that have been aggregated due to mergers
and acquisitions. In some cases, the database of record may be file cards or
spreadsheets. Since Sarbanes-Oxley compliance requires accurate reporting of
assets, a great deal of time and money is often spent collecting and analyzing
this information in recurring consulting projects. This money could more
profitably be used to automate the discovery and reconciliation process, with the
follow on benefits of being able to use the same data to support Network Integrity
for logical inventory and configuration management.
Solving the physical inventory problem will improve asset utilization and support
accounting for assets, but will do relatively little to improve order throughput or
reduce outages. Reduced fallout (or improved throughput) requires an accurate
representation of logical inventory, so that the resources designed for a service
are used to implement it. Reduced outages require perfect configuration of these
resources, as configuration errors account for more that 70% of network outages.
We’ve seen that automating these three classes of data integrity problem share
a common set of solution requirements, and that these requirements are largely
independent of the underlying network/service technology.
The reason that these solutions can be network technology independent is that
the complexity is largely in three technology independent areas:
- Collect: Collection of large amounts of network data in a secure and non- disruptive way. Data collection can’t unduly burden the network, nor can it expose the configuration data to security risks. This class of problems must be solved once, enterprise wide, or the “silo” solutions represent another layer of exposure.
- Analyze: Analysis of configuration data. The rules required to understand whether configuration data is within bounds are complex, but not dependent on the underlying data.
- Resolve: Best practices for discrepancy resolution. The escalation, confirmation and correction processes tend to be enterprise specific, and technology, agnostic. Engineering these once, and applying them everywhere, is much more effective than allowing technology specific silos to behave, The implication of this is that a common set of practices and systems can be applied enterprise wide. This holistic approach can be achieved if a number of key challenges are met.
