This is the functional specification - the "what" that comes before the "how".
- Model the whole thing: all the things, and all the relationships between them.
- Model the network as it is, however messed-up that might be - both the design and the reality.
- If it doesn't fit some theoretical model of how things should be deployed, too bad. Model it anyway. A tool like this that gets in the way for ideological purity, is a tool that gets in the way of solving the problem.
- Distinguish between how things should be, and how they actually are.
- These are different things, even if they have the same value.
- Distinguish between values you intend, and those that have to be discovered.
- One one hand, subnet allocations; on the other, SNMP index IDs.
- Conveniently, these correspond neatly to "intended" and "actual" groupings, so they can be managed together.
- Automation-friendliness is vital, so build the API first, then build the GUI on top of that.
- Anything you can do with a GUI can also be automated.
- If the vendor-supplied GUI doesn't suit the user's use-case, now they can build one that does.
- User-extensibility must be provided, and must be first-class.
- No one model fits all use-cases, and all organisations have some custom use-cases. Provide users with a way to seamlessly extend it to cover any gaps.
- Make sure this integration is first-class, not some afterthought gaffer-taped to the side.
- People don't always have the full depth of detail. Allow for this.
- Enable users to record whatever information they do have on hand, and evolve the picture as new information comes to hand. E.g, you can assign an IP address to a host, then move it to the correct interface, then assign that interface to a routing instance, all without losing any information such as incoming links from other things.
- Design from the start to cover multiple organisations, because very few IT organisations are totally air-gapped.
- Troubleshooting becomes much easier when you have reference information about connected networks and how they relate to yours.
- This also allows for mergers, spin-offs, subsidiaries and subcontractors.
- Enable modelling of secondary resources, i.e. things that only make sense in the context of a parent entity.
- Open standards beat proprietary ones.