Stephen Morris is freelance writer and guest contributor to Network Noise.
We live in an era of increasingly fragmented supply chains. What does that mean? Well, when you buy pretty well any electronic device from a sat nav to an iPhone or iPod touch you no longer tend to have a one-stop shop experience. Gone are the days when you paid over your hard-earned dollars and received a shrink-wrapped package containing all the goodies you need!
Instead, for many such devices nowadays, you may have to separately purchase an AC charger. It’s the same story when you want to download additional software for the devices, e.g., look at the hugely successful iPhone app market. Ditto for extra maps on sat nav devices.
This is all a different way of saying that the rich and complicated supply chain is fragmented – you receive value with such devices above and beyond your initial purchase. That value is augmented over time with the addition of new hardware and software. I guess it’s the vendors’ hope that this model will also extend the effective life of the device and help to form a more sticky relationship with the customer. One might say it’s the 21st century version of vendor lock-in…
Network management (NM) software doesn’t really fit so well with the fragmented supply chain model. One reason for this is that NM software is typically a relatively small but key part of a massive investment in network hardware. So, NM software tends to adhere to the older one-stop shop model with occasional fork lift upgrades to apply changes. Worse still is the fact that most NM packages are vendor-specific with some better than others but no overall guide for developers. So, what about NM software upgrades?
The NM upgrade points become a critical moment of possible failure. Contrast this with the upgrade of an iPhone app where you are unobtrusively notified of an update and you click an app icon button to download it. Now, clearly we’re not comparing like with like! An iPhone app is microscopically tiny compared to an NM application. However, I think an interesting question suggests itself: Is there scope for a more fragmented approach in the NM software area? I think there is scope and it might come from embracing two things: more generic modelling and phased delivery.
MPLS VPNs and VLANs and generic modelling
If you look at a typical MPLS VPN and then look at a VLAN you won’t see too much crossover. For one thing, they operate at different network levels. However, taking a more abstract view the elements of VPNs and VLANs do exhibit certain similarities, e.g., both of them contain groups of nodes that are combined together to form an overall service. In addition, VPNs and VLANs are configured with rules specific to the required service and the constituent technologies.
By viewing the NM facilities (i.e., VPN, VLANs, nodes, rules, etc.) as more generic entities, it may be possible to model them in a more generic way. Object-oriented programming languages can help in this approach by allowing the definition of high-level base classes.
This sounds difficult but it really isn’t: you start with a node type to model any node. This can be used as part of a VPN or a VLA N. Then, you use a sub-class to add technology-specific attributes and capabilities. In addition to this, polymorphism in turn allows for a more elastic model when it comes to device-specific attributes and capabilities (see the references section for some articles on these points).
In other words, skilful use of the object-oriented approach should yield a hierarchical, polymorphic object model that can match the use and management of the real world devices and networks. In this context, arriving at a more generic model is down to the skill of the NM software designers and programmers.
What about the delivery of such software to the end user?
As NM developers, should we necessarily wait until a given feature is absolutely complete before deployment? I tend to think a more phased or agile approach might be useful, i.e., deliver a feature at the 80% completion mark and get some user feedback. Then, complete the feature with the benefit of the feedback.
This is a little more like the iPhone distribution model. Now, I’m not suggesting putting an 80% complete NM package up on a live network worth millions of dollars. I’m just suggesting that a customer might be interested in seeing features in a test scenario before they’re set in stone for release.
With this approach, the developers of the NM software can get valuable feedback from expert users. This can be used to create a more solid value proposition for the final software release.
Generic software and phased delivery: a fragmented supply chain?
So, the two concepts I’ve described are: generic object-oriented software and phased delivery. These aren’t new ideas – far from it. However, a substantially more generic approach would help to avoid duplication in NM code. Done right, it also facilitates software upgrades.
Phased delivery is likely to be more contentious – nobody likes customers to see their software defects. But, there is a higher purpose in this and if vendors and customers sign up to a more fragmented approach then I think this is a benefit for all.
Is there a silver bullet in this? Ideally, the developers of one NM package should be able to move from one vendor company to another and not have a huge learning curve. Likewise, end users should be able to chop and change their NM software toolkit. In other words, building and using NM software should be a whole lot easier than is currently the case.
In short, I think breaking up the NM software supply chain is important and necessary. This is particularly the case as we all rely more and more on different networks – effective management of these networks is no longer a choice, it’s a necessity.
These ideas are discussed at much greater length in my books and articles at:
In particular, my NM book describes techniques that NM developers and designers can employ to better model networks. I’ve called one of these approaches: Linked overviews. This is useful tool for gathering together the essential attributes of a given technology prior to defining a management model.
End users could potentially also use this approach to communicate their needs to NM vendors.
Tags: Guest Blogger