Executing Product Strategy for Software-Defined Networking
Harvey Wong 270001XCWC Visits (2168)
I’ve been following with keen interest as network infrastructure equipment manufacturers (NEMs), including IBM, have had to quickly respond with market messaging and product strategies for software defined networking (SDN).
In simple terms, key attributes of SDN include:
What’s interesting is that the demand for SDN is being driven by major communications service providers and major enterprises, versus the network equipment manufacturers (NEMs). If you were a telecom service provider or other major consumer of network infrastructure equipment, SDN is in theory very attractive for various reasons:
- Wire your network once and only once
- Use centrally controlled, lower-cost switches from multiple vendors
- Flexibly and rapidly control and automate your network with vendor-neutral software
- Better support for multi-tier applications that require complex interaction between server, storage, and network resources
However, SDN also potentially upheaves the communications equipment industry. While NEMs all support networking standards, a NEM generally wants to optimize product margins by promoting vendor “lock-in”, seeking any competitive edge to own more of the network and make it difficult to mix-and-match equipment from different vendors.
SDN could disrupt everything for the established NEMs. Historically, part of a NEM’s technical secret sauce and differentiation is in the control plane logic embedded in ASIC’s and software on the routers. In SDN utopia, control plane intelligence would be migrated from routers and switches to a central controller, resulting in commoditized “dumb” network gear that could be easily mixed and matched from different vendors. This would thereby eliminate vendor lock-in, making it harder to differentiate, and result in lower margins for the cheaper network equipment.
To develop a product strategy in response to the SDN movement, NEMs are contending with a challenging and very dynamic landscape.
New Players and Competitors. Numerous high-profile and credible start-ups have emerged in the market, grabbing attention and driving some of the SDN thou
Battleground for the Central Controller. The Central Controller is the heart of SDN, a software platform that enables network architects and administrators to programmatically deploy network routing, applications, and policies without needing to re-wire or re-configure individual network elements. This is ground zero for SDN mindshare and marketshare, and where numerous initiatives are in play, open source and proprietary, jockeying to establish a market position.
Evolving market requirements. SDN is still in “early adopter” stage but moving fast. Companies like Google and Amazon have proven out the concept. However, market requirements to support service providers and major enterprises are still evolving. What are the various use cases that need to be supported? What type of programmatic interfaces should be presented? What types of network applications need to be supported?
In this challenging landscape, I’d like to point out how well-oiled product management and software development processes are critical for a NEM to execute its SDN product strategy, particularly in 3 areas:
Executives and product managers need decision support that facilitates data-driven analysis of product decisions. For business-critical decisions that directly affect product strategy and roadmap, you need to effectively evaluate data and different “what-if” scenarios. You want to collaboratively involve and seek input from various stakeholders, while minimizing influence of the “loudest voice in the room” or internal politics.
Complexity. SDN has wide ranging impact to a NEM’s product line. From supporting OpenFlow and IEEE 802.1Qbg to network overlay strategies to developing a central controller software platform to integration with OSS/BSS, an SDN product strategy is likely multi-prong. This naturally implies complexity on multiple fronts, especially if the goal is to offer a simplified central single network view of the network (that hides all of the underlying complexity).
To manage complexity, the engineering organization will need to effectively manage requirements, especially impact analysis of evolving requirements, to build the right products and achieve quality at optimal cost. Also, building products is a team sport, so use tools to facilitate communications, coordination, and just enough governance. Lifecycle traceability is another powerful tool in managing complexity. Having visibility into the relationships and dependencies between requirements, designs, tasks, source code changes, builds, tests, and other artifacts will really provide valuable information to make day-to-day engineering decisions, e.g – has this new requirement been implemented and tested, and in which build? which requirements do these failed tests impact, and which customers do they affect?
Agility. With SDN’s focus on software, NEMS have an opportunity to collaborate closely with key clients, quickly iterating and building capabilities, seeking customer feedback at each stage. To do this, the objective and challenge is to enable Agile practices across globally distributed software engineering as a cohesive team of teams, while balancing velocity, cost, quality, and resources. The key here is to have tools and automation to enact processes, facilitate communications, and provide real-time visibility into project health across various metrics.
You can hear a podcast discussing SDN and how Rational can help NEMS execute their product strategy here.