Clear, well-formed use cases have always played an important role in executing focused software development initiatives and successful sales programs. With SDx technologies evolving so quickly, actionable use cases are becoming even more important for both vendors and end users.

SDx infrastructure (SDxI) is responsible for supporting and connecting billions of users and devices to millions of services, which means the networking problems we face now are exponentially bigger than networking problems from just a decade ago. The new Internet infrastructure requires a different class of hardware and software designed to provide the scale, automation, and flexibility required by SDx applications and the cloud. This means an entirely distinct set of use cases to make SDx technology relevant to IT today.

Coherent use cases are vital to the adoption of software-defined networking (SDN) and network functions virtualization (NFV), both of which are important pillars in SDxI. But creating use cases is no easy task when vendors working to claim their share of the SDx pie are defining the technologies for their own purposes. Establishing widely understood SDxI use cases will help our industry have more productive conversations about customer needs, technical requirements, and relevant business cases for SDN and NFV.

Understanding and working with the right use cases can help you harness SDx technology to both save and make more money for your organization. In this installment of our series on the future of the SDx infrastructure, we look at why we need a new class of use cases for SDxI, and we outline the taxonomy of use cases we developed over months of discussion and debate with end users, providers, vendors, and each other.

When we talk about the new SDxI use cases, we’re not suggesting that traditional networking, compute, or storage use cases are irrelevant or will go away. In the same way that COBOL and mainframes still exist because they solve the same important issues they did when they were introduced 50 years ago, the general set of infrastructure use cases we all know has not suddenly become irrelevant with SDx – just largely incomplete.

The rise of SDx has released an unprecedented wave of unfamiliar infrastructure issues. The emerging SDx infrastructure is fundamentally changing organizations and causing a shift in the critical roles of functional executives, technical architects, and software developers. Clear use cases provide people in these roles with the framework and application information they need to understand SDx technologies and make buying decisions.

Under traditional networking models, use cases were more obvious because customers would choose from a small number of architectures and make the selected architecture work to solve their business problems. In an SDx world, applications are so tailored that applications themselves have become the competitive differentiator.

For example, as we called out in our last post, AirBnB built out the cloud-based back office and call-center routing applications that form the backbone of its business, while Uber built the communications and scheduling systems that serve as the nerve center for theirs. Next-gen customers like these are far less interested in features than they are in defining clear use cases that will help them tackle their most pressing challenges and evaluate potential technology purchases against the use cases.

We believe clarity around use cases is so vital to the adoption of SDx technologies that we’ve created a new SDN and NFV use cases section on SDxCentral. Defining the use cases was not a straightforward process. Not only does everyone use slightly different terminology to describe slightly different needs and potential ways to fulfill those needs, but we also had many discussions ourselves about how to categorize certain use cases. We put a lot of thought and debate into our resulting SDN and NFV taxonomy of the six the most common SDN and NFV umbrella use cases today:

1. Network access control: Set appropriate privileges for users or devices accessing the networks, including access control limits, incorporation of service chains, and appropriate quality of service. To maintain security and compliance while providing convenience, generally follows users/devices as they connect from different parts of the network.

1. Network virtualization: Create an abstracted virtual network on top of a physical network, allowing a large number of multitenant networks to run over a physical network spanning multiple racks in the data center or locations if necessary, including fine-grained controls and isolation as well as insertion of acceleration or security services.

1. Virtual customer edge: Virtualize the customer edge either by creating a virtualized platform on customer premises (on-premises virtual CPE) or by pulling in the functions closer to the core network on a virtualized multitenant platform hosted either in a carrier point-of-presence, regional data center, or central data center (enterprise, telco or over-the-top cloud SP)—sometimes called virtual CE (customer edge).

1. Dynamic interconnects: Create dynamic links between locations, including between data centers, enterprise, and other enterprise locations, as well as dynamically applying appropriate QoS and bandwidth allocation to those links (including bandwidth-on-demand, or BWoD).

1. Virtual core/aggregate networks: Virtualize core systems for service providers including mobile support infrastructure such as vIMS, vEPC, as well as dynamic mobile backhaul, virtual PE, and NFV GiLAN infrastructure.

1. Data center optimization: Using SDN and NFV, optimize networks to improve application performance by detecting and taking into account affinities and orchestrating workloads with networking configuration (mice/elephant flows).

For more information on each category, check out the SDN and NFV use cases section of our site, where we provide a summary of each use case; define which customer segments care most about a specific use case (cloud service providers, enterprises, or telcos); share what customers have told us about why they care about a particular use case; explain what business problems are solved; highlight what business value is expected to be created; and outline how (or if) SDN and NFV can solve that use case.

We hope this taxonomy will help align terminology, simplify conversations surrounding SDxI, and ultimately help further the adoption of these incredible next-gen technologies. As always, we encourage you to share your thoughts on some of the ground we covered here, or general thoughts about the future of infrastructure in a software-defined world. Add your thoughts in the comment section below, or email us.

In our next blog post, we’ll look at specific attributes of the SDx infrastructure.

1. What is Software Defined Everything - Part 1: Definition of SDx
2. Software Defined Everything Part 2: Cloud Infrastructure
3. Software Defined Everything Part 3: SDx infrastructure
4. Software Defined Everything Part 4: SDx Infrastructure Buyers
5. Software Defined Everything Part 6: Infrastructure Attributes
6. Software Defined Everything Part 7: Infrastructure Form Factors & Delivery Models
7. Software Defined Everything Part 8: Succeeding in an SDx World