Just as the shift to software-defined everything (SDx) is affecting business models in just about every industry, it’s also changing the IT purchasing and procurement process as we’ve always known it. In our past lives, when we (Roy and Matt) used to work at IT infrastructure vendors, we saw the typical marketing messaging centered around pushing out: “sheets and feats,” or data sheets and features, on their customers. When next-generation networking arrived on the scene starting with SDN, we noticed the sales and marketing processes remained mostly unchanged. At least it did at first.

Now, the rise of SDx is causing a fundamental change in how IT infrastructure is procured and acquired. Our experiences shaped our perspective that Software-defined infrastructure (SDxI) is the next generation of infrastructure required to connect all the new software-defined devices and applications to their networks, each other, and ultimately to end users. In the same way that SDxI is more than just the sum of its software-defined components, the technology selection process framework for SDxI is more than just finding the best individual parts for your system based on “sheets and feats.”

Here, we’ll identify the new technical and economic buyers, explain how they’re different from buyers of the past, look at how they obtain new SDxI infrastructure, and provide insight into their changing needs.

Just a few years ago, the buying process was still relatively straightforward. The network engineers bought the networking gear, the storage engineers bought the storage gear, and the server engineers bought the compute gear. Sales reps would find the right people, show their charts, and give their pitch. “Look at my 40-gig port,” or, “Look, we support Dot1X or XYZ.” Vendors laid out the offerings, buyers selected the products with the most impressive features and best price, and IT found the applications that worked within the architecture framework handed down to them.

SDxI is turning this entire process on its head. New SDx application requirements and the growing prevalence of the cloud are causing a shift toward a more application-centric buying framework. In an SDx world, networking engineers no longer unilaterally decide the network architecture applications must work with. Now, the needs of the business applications drive the architecture of the network, rather than the other way around.

Today’s SDxI buyers are not just looking for infrastructure - they’re looking for a whole solution that solves one or many specific business problems. The stakeholders building out SDxI must support this new generation of applications that essentially define their businesses. For example AirBnB building out their cloud-based back office and call-center routing applications, or Uber building their communications and scheduling systems— these SDx applications are their competitive differentiator. It is these applications drive the underlying requirements for SDxI.

SDxI incorporates increasingly sophisticated, software-driven, and often integrated compute, storage, network, and security technologies. These four pieces have to come together to work within the cloud architecture to support these new applications. According to a study from Verizon Enterprise Solutions, more than 70 percent of businesses expect to have external-facing applications in the cloud within the next three years. This makes the cloud not only a de facto part of the infrastructure, but also a primary factor in purchasing decisions.

The fundamental shift toward application centricity and cloud architectures is changing who makes the buying decisions. The days when network engineers ran the networking show alone are fading fast, and a new group of players has become more influential and responsible for IT infrastructure purchasing:

Most business executives used to be content to leave the nitty-gritty of IT purchasing confined to the CIO or “IT guy.” Now a new generation of line-of-business managers is coming to power. Tasked with solving specific business problems that are increasingly dependent on software, the new LOB managers are driving their teams to build specialized applications in the same way Facebook, Apple, or Tesla do in their organizations.

LOB managers still delegate technical decisions to other people, but now they are intimately involved in infrastructure decisions that could significantly affect margins or profitability. They define the budget and usually have final economic say.

The new LOB manager’s main criteria for making infrastructure purchase decisions are: 1) Does the infrastructure enable his/her application to do what it needs to do?; and 2) Does the selected infrastructure fit within the cost/profitability profile?

Application architects determine the feature, performance, and security requirements of the application. They define the software architecture involved and essentially specify what capabilities the underlying infrastructure needs to provide to an application to allow it to scale and perform according to the business criteria set by the Line-of-business executives.

Cloud architects lead the infrastructure team in figuring out how to build the cloud infrastructure to support each and every application They design the infrastructure to meet economic requirements laid out by the LOB executive and technical requirements laid out by the application architect. The cloud architect defines the appropriate interfaces and constraints for each of the network, storage and server engineers, who in turn select and tune components to meet the cloud infrastructure performance, scalability security and reliability requirements.

The DevOps person/team (as its development + operations name suggests) oversees the collaboration between software developers and the IT operations teams. DevOps is responsible for deploying the application designed by the application architect onto the infrastructure designed by the cloud architect, to meet the business uptime and operations cost envelop provided by the line of business executive. The DevOps team is also responsible for maintaining the ongoing application and for ensuring it scales up when traffic increases and that it stays operating in the face of hardware or other system failures. Their main criteria in evaluating infrastructure components is how easy the pieces are to integrate into their DevOps automation tools.

Together, these people form the new center of where infrastructure buying decisions are made. Often, only once they’ve designed the application and the cloud infrastructure does the network architect get involved. And today, that network architect has a more detailed list technical requirements and business constraints around the parameters of the network, reducing their freedom in making unilateral technology and product decisions. This story is repeated for the storage and compute architects, who now also play a supporting role within purchasing decisions.

Today’s SDxI architects usually have come of age with the web (at least professionally) and are very comfortable with next-gen technologies, DevOps tools, and scalable architectures with a blend of private and public clouds. Based on profiles of the SDxCentral audience, we see today’s technical buyers assuming architecture roles at a younger age than previous generations of buyers. Many of these architects progressed rapidly through the engineering ranks, accelerated by the rapid uptake of the Web 2.0 and cloud infrastructures. Our data and experience suggest that this new SDxI buyer is in high demand and are highly career-mobile with rapid job changes. As a result, today’s buyer tend to identify more with their roles than with their companies. SDxI architects like them tend to educate themselves in the latest infrastructure developments not only for the sake of their current jobs, but also for potential next ones.

From our experience, we see that SDxI architects and buyers are far more proactive and product savvy than their previous counterparts when it comes to researching potential applications and frameworks. Favoring web search and social media, they seek the information they need online, and hanging out virtually with their peers to exchange information. Not surprisingly, many SDxI architects are busy and don’t show up at traditional tradeshows. We’ve seen that they like to stream or watch archives of online sessions that interest them. This means that by the time a vendor walks in the door, an SDxI architect probably already has developed a strong opinion about the frameworks he/she is interested in.

In our next blog post, we’ll explore SDxI use cases and how they differ from networking use cases of the past. 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. We look forward to hearing your perspective!

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