A couple of days ago I explained how cynicism and regret are valuable thinking processes for a Network Designer. The long foreseen failure and subsequent breakup of Nortel presents a opportunity to look back with regret and learn cynical lessons for the future.
Even Big Companies Fail
The biggest lesson to be re-learned is that even the biggest companies fail. Nortel and Cisco were the top two players in the Voice/Data marketplace at the end of the century.
Lesson:You might think Cisco, or IBM, or EMC, or VMware may be too big to fail but that isn’t true, Nortel proved it.
They didn’t integrate
I have been working with Nortel since 1996 or so, when they were called Bay Networks1. When Bay Networks and Nortel merged in 1998/1999, Nortel was widely hailed as the messiah of the predicted voice/data networks, and reinforced the popular management concept (of the time) that a company with a large portfolio of products would be better than smaller, focussed companies.
But the integration didn’t work. To this day, most every engineer still thinks of the Nortel data products as Bay Networks rather than Nortel. This lack of integration (real or imagined) meant that my perception of Nortel was never very strong. This undermined their overall place in the marketplace.
Lesson: If a company merges or acquires companies, and the merger doesn’t look good, look closely to see if there is some deeper problem.
Proprietary Features means no Exit – Choose Open Standards
If you have based a network design on any Nortel specific features or hardware, you will experience some difficulty. Generally, Nortel’s Enterprise Data division has been one of the best companies and setting and following standards. They were, and are, regular contributors to IETF, 802.1 and so on. Nortel’s voice products are completely closed and proprietary and you must be a little concerned at the moment.
As a designer, it’s time to remember that open means integration with other vendors and that a migration with mixed vendors is possible. Right now, we are seeing quasi-proprietary or marginally-closed solutions coming from the Storage marketplace and reinforced with ‘validation’ and ‘certification’ programs. Is this a sign of poor technology standards, poor implementations or something else ? If vendors can’t interoperate with technology based on standards what does this mean ?
Lesson: Avoid proprietary features even if the vendor offer such features.
Service Levels Going to be Bad
When your vendor fails, the support doesn’t always get bad immediately but it does get poorer and poorer over time. No matter who buys them, the existing products are never as important as the new products.
If you remember when DEC/Digital Equipment was acquired by Compaq, the Networks Products Business Unit was not part of the purchase. No one ever purchased it and the maintenance contracts were sold to a company who warehoused spares and provided no further software updates.
Lesson: Maintenance and support matters. but if your vendor fails, you don’t have many choices.
Strategy Overhaul
If you had a strategy based around a vendor that is failing in the marketplace, are you able to change to meet this requirement. In my experience, once you have made a significant investment in training and maintenance of a given vendor, large companies are very reluctant to change that strategy.
Are you able to overhaul your strategy and change vendor ? Do you have a mechanism that can get agreement to walk away from your supplier to a new one ?
The Value of Open Standards
And take this opportunity to be thankful that networking is an industry of open standards. Unlike storage networking which emphasises ‘validation’ and ‘certification’ for products that are supposed to work together, Data Networking demands that vendors interoperate and is one of the greatest strengths of our industry.
Wrap Up
The failure of Nortel is a sad story, and I have always wondered why Nortel didn’t do a good job, but we should always learn from what happens around us. Hopefully, I have covered a few of the topics that we could learn. I will try to remember them in the future when I’m selecting products and vendors in my designs and architectures.
Footnotes
- actually, Wellfleet but no-one wants to remember back that far surely [back]
Loading ...
About Greg Ferro
Come on, don’t neglect the old farts
I remember the days when you had to know the SNMP OIDs to configure a Welfleet router with what they called “CLI”. AFAIK they only sold one reasonably-sized box in Slovenia and it quickly became a flower stand.
But that also meant we had collections of Perl and TCL scripts that we used to configure them as well. And that was a good technique for learning how to manage our networks.
That’s a feature not a problem.