“There is no logical way to the discovery of these elemental laws. There is only the way of intuition, which is helped by a feeling for the order lying behind the appearance.”
Further to yesterday’s blog about network modelling, I had a task back in 2001-ish to help a vendor develop their first-ever auto-discovery tool. It was such a thrill when we got it working and the customer was blown away by what we were finding.
As a starting point to modelling a network you need to have a comprehensive knowledge (or to learn along the way) of all the dot-points listed above. Then one of the keys is to understand the hierarchy of objects that you need to model (eg a location is required for a device which, is required for a card, which is required for a port, etc).
Now this might not be relevant for every OSS but I’ve always found that it’s important to build up the data sets in the same way as you would build a network. For example, you first find a location, then you build a building, then a rack, then you insert a device, then you insert cards in a device, etc. Build up your data sets in the same sequence (ie load location records first as they will be reference data to assign a rack to).
I like the concept of TM Forum’s MTOSI being an XML-based approach that allows you to define any hierarchy of objects you like (eg a location is required for a device, etc) out of the NE/NEMS/NMS layer and then map it into your OSS.
Then the really exciting part comes into play if/when you try to map cross-domain data like circuits. SDH is a great starting point because it has highly structured circuit hierarchies but trying to map that to the OSS‘s data structures tends to be the greatest challenge.
If you can discover cross-domain circuits then you definitely deserve high-fives from everyone else in your team.
What has been your greatest achievement in OSS?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email