Are You Solving the Right Problem?
With all the intent-based hype (and the previous SDN-will-rule-the-world-hype) you’d think that the network is the ultimate ossified roadblock on the path to agile nirvana.
You’d be totally wrong (and you’d deserve it – never trust a vendor peddling a product).
Here’s an amazing discovery I made when I was still running on-site SDN and network automation workshops.
Speaking of network automation workshops: I mostly replaced them with the network automation online course and network automation webinar track, but if you really want to attend an on-site event I’ll be running one in Rome in October 2017 and probably another one at Troopers 18.
I always started them with “what do you think is the biggest obstacle in your IT and how would you automate that?”, and once I got this reply from someone whose perspective was slightly larger than just networking:
If only we could deploy VMs faster. It takes a month to get a new VM because so many teams (server, storage, security, backup, AD, monitoring…) have to touch it. How could we automate that process?
Lesson learned: figure out what your most pressing problem is. Contrary to what the vendors claim, it might not be the network.
Next step: follow the 80-20 rule and fix the first 20% of the problems you have. They are usually the easiest to fix, and might result in biggest payoffs.
Finally: sometimes it’s the process, not the technology. You’ll never fix a broken process by replacing it with technology, all you’ll get will be a technology-assisted broken process.
Also: replacing whole teams with technology sounds great if you hate dealing with pesky underlings, but you’re just replacing your team (example: network engineers) whose only focus should be the well-being of your company, with someone else’s team (example: programmers working for an intent-driven vendor) whose focus is completely different (example: generating revenues for the vendor). Why do you think that would give you better results?
This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.
We use templates and powershell not for speed but for uniformity.
In most European telcos in smaller countries, they do not have so much customers that the daily transactions could not be made with simple semi-automated methods.
The SDN story has not improved significantly the business case, since 80-85% of the product cost is on the business side. Going with SDN is a fashion and a pressure from the vendors. They just stop supporting some technologies, the volume drops, the prices go high.
For example, there is nothing wrong with classical TDM/PDH/SDH. Juts it is getting out of fashion, so it becomes less available in all terms and more expensive. Although the technology cost is small, but it shall not increase for established products. So sooner or later you are enforced by the vendors to reinvent the wheel. But it is bad for the business, so telcos try to postpone such changes as much as possible. Selling classical phone services or leased-lines is the best business from the financial point of view. It has such a high profit rate, that nothing else can even come close to it...
There is one exception to the fashion driven changes, when an old technology does not scale up. Like the SAR function in ATM. No one was interested to make a higher speed version, so you were forced to change to some other technologies.
Of course, the vendor pressure of fashion comes from their financial need of continous cash-flow. They have to enforce their customers for buying something new. Sooner or later the telcos will revolt and take back some of technology into their own hands. See ONOS/CORD or ONAP...