Don’t let yourself be erased from the business needs narrative


A CIO of a retail chain recently issued an edict that all requirements for networking must be stated as business needs, including all RFIs, RFQs and internal proposals. No networking protocols, features or terms are now permitted. At first glance this seems like a relatively simple instruction, but the IT staff struggled to articulate business needs and map them to network capabilities. The CIO is imposing a discipline of asking “why” three times to try to understand and separate the inertia of past choices from what their business needs today. I believe the CIO is wise in trying to connect the business needs to network capabilities.

Speaking the language of the industry

Networking professionals are being left out of the narrative. We are deemed a necessary evil rather than a partner in producing products and services. We are the people that slow things down, make things harder and budget for things people do not understand nor value. Becoming part of the narrative requires that each networking professional understand and anticipate their business’s needs. In fact, I would argue that the public cloud, bring your own device and shadow IT are the result of networking not being part of the narrative.

Every networking engineer should cancel his or her CCIE certification efforts. Recoup the tens of thousands of dollars and time spent learning about specific technical approaches of a single vendor and reinvest that same time and effort understanding about the business needs for networking. If an engineer works for an energy company, they should spend time in the field. Talk to people about how they use data and devices. Catalog all the services and uses of the network. Understand their frustrations at the business need level. If they work at a manufacturing company or heavy industry, they should read about the Industry 4.0 initiatives. To be a successful networking leader in the future, engineers must speak the language of the industry, not their supplier.

Making smarter networking decisions

Recently, I learned the average Fortune 500 company has over 1,100 VPCs at AWS. Each one was acquired independently for a single use. Public clouds are often easier, quicker and cheaper than standing up servers in a corporate data center. However, this practice is creating a larger and larger number of private network segments that need to be internetworked. As a networking professional, we need to internetwork many of these VPCs with all of our sites in a secure fashion. Keeping inter-VPC traffic at AWS clearly makes sense, but should one build a classic anywhere-to-anywhere network with ACLs everywhere? Or should be just bridge the networks with tunnels/routes that are necessary? Do we need firewall technology on these routes?

Leave a Reply

Your email address will not be published. Required fields are marked *