“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.”
Daniel J. Boorstin
Auto-discovery is a tool of great power in the OSS tool-kit. However, there are a few things to keep in mind when planning this part of your OctopOSS:
- You don’t want auto-discovery to auto-populate your OSS database. There are too many misleading events that appear like an inventory change (eg flapping ports) that are actually misnomers
- Your process must be designed so that auto-discovered inventory changes are manually accepted into the database to disregard the above-mentioned noise
- Auto-discovery capability provided out-of-the-box by the vendor doesn’t necessarily mean that it will actually work directly from the box. In most cases auto-discovery needs to be configured to pattern-match the data against the CSP’s specific network/data design (eg naming conventions, topologies, data model in the OSS, etc)
- These auto-discovery mappings need to be identified in the data migration plan
- The more initial data-migration that can be done via auto-discovery tools, the better because that’s implementing the long-term solution rather than having to develop once-off data parsing and loading scripts for the data migration phase
- The data migration plan has to be led by the vendor because they know their data structures best and know what data needs to be mapped into their system to allow the applications to function correctly (eg sequence of loading, data structures, referential data, etc)
Developing and configuring auto-discovery tools is one of the more challenging, but exciting activities when designing and building a new OSS