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?

Cisco claims nearly all workloads will be in a public or private cloud within three years. Business logic dictates that each workload has a defined set of allowable users and a defined set of related or supporting workloads. Ideally, one would describe network requirements in the form of a map of connectivity for each workload to its related workloads and users. Understanding users and related workloads is not easy, and traditional network segmentation doesn’t work well. This is because workloads are chained and shared, and users are often authorized to use multiple services.

Focus on requirements

Another frustration is that the networking function provides connectivity, but the security function subsequently limits connectivity by controlling access. Network routes are dynamic and self-healing, whereas access controls are provisioned, physical, and static. The narrative used by service owners is “elastic, dynamic, multi-location, simple” while the networking narrative includes “ISPEC tunnels, IKE servers, BGP, NAT, Dynamic DNS, Load Balancers, Firewalls, ACLs, MPLS, MP-BGP, NAC” plus lots of provisioning. The provisioning is so complicated we now call it orchestration.

The new narrative between service owners and networking professionals needs to focus on services and their requirements. Every service of value requires one or more packets to traverse from client to server through a network. These packets associated with a service constitute a session. Rather than routing packets, networking professionals need to start thinking about sessions of packets. Sessions have one or more service addresses, a direction (client to server), they have bandwidth behaviors (voice, video, HTTP), they have lists of acceptable clients (IP address, netmask, VLAN, equipment type, etc.). Likewise, networks need to provide analytics for services and sessions as a primary feedback loop for automated network adjustments (elasticity).

The networking layer needs to understand services at key network borders. Elastic, dynamic, multi-location, simple networks cannot be orchestrated. For networking engineers to rejoin the narrative, networks must speak the language of services – sessions. When a network engineer provisions services instead of CIDR blocks, then we will become part of the conversation. When network elasticity is responsive to service needs, instead of brute force over provisioning, we will begin to add competitive advantage to our organizations.

We are all speaking the language of the dominant supplier in our space, we are studying for certification by a supplier, and we are no longer valued by our organizations. Rejoin the conversation by tuning into the business’s true needs. Become part of the narrative of your organization.