|By Michael Bushong||
|May 21, 2014 11:18 AM EDT||
When we think about what’s next, our frame of reference is almost universally anchored to what we are doing now. We look at how things are, and then we aim our sights forward. In some cases, we might make incremental moves ahead; in other cases, maybe we look for improvement by orders of magnitude. But regardless of how far forward we reach, our starting point is where we are grounded today.
This creates an interesting dilemma in technology generally, and in networking especially.
Networking is a capabilities-driven industry. We are constantly expanding what we can do with networks. In some cases, it might be how we handle complex policy, in others how we solve interesting traffic challenges. Whatever the problem, we have thus far been able to come up with some way to address it.
Some might read this and think: it’s not all capabilities! While it is true that the networking industry has spawned a number of efforts over the years aimed more at usability than capability, the inability to make a large business out of network management is a running joke. In fact, when we think of companies that have been very successful in creating useful products in the usability space, we probably think of companies that are a lot smaller than their tech justifies (Tail-f comes screaming to mind personally, but there are others).
So networking really is dominated by efforts around new capabilities.
But who invents these new capabilities?
Invention falls on the backs of the vendors. This is an obvious point. But what is the frame of reference from which the vendors build?
We all build from our current starting point. So as we evolve networking, we evolve it forward from our current base set of capabilities. There is nothing new in that statement, but consider this: what happens when an inventor’s ability to churn out new things outpaces a consumer’s ability to adopt it?
This is actually a dangerous state to be in. Useful innovation requires iteration. You need to come up with new ideas, prototype them, test them, collect feedback and iterate. But when new capabilities outpace the bulk of the market, two things happen: first, the capabilities go unused for the majority of consumers, and second, the lack of use inhibits the natural iterative process.
VMWare as an example
Let’s apply this to some specific industry examples. In using these examples, I don’t mean to judge the efficacy of any particular solution. Instead, I want to point out the strategic implications of this dynamic.
VMWare very famously pushed into the networking arena through the acquisition of Nicira a couple of years ago. With the acquisition and subsequent product launches, they effectively created the network virtualization space. They have built and shipped a product (NSX) that is the leader in this technology.
If you watch the technical dialogue around NSX, they have been building around their NSX beachhead. They talk about distributed firewalls now, and it won’t be long before they expand beyond that. They are clearly inventing quite rapidly, building lots of functionality that has the potential to be extremely useful.
Adoption, not innovation
But the issue that VMWare faces is certainly not related to their ability to innovate. Their primary struggle has to be with adoption.
When you create new categories of products, you sometimes address problems that people do not know they have. You build solutions that are beyond what a user’s current capabilities are, so the path from here to there is non-obvious.
Put slightly differently, while the frame of reference from which a vendor innovates is their product, the frame of reference from which a user grows is their deployment. In the same way that networking vendors naturally move forward incrementally, users will tend to make incremental architectural changes.
This means that product strategy has to include more than capabilities. It has to include migration as well. Migration is not just another way of calling out an insertion strategy. It really means that you have to strategize explicitly about how customers move from A to B. This means understanding what they perceive the transition to look like. What is their foundation? How does a shift impact things like training and process? How does a change intersect budgeting decisions? Do expanding capabilities muddy the approval chain as you bridge functional teams?
Understanding this, you can start to shape a strategy that extends beyond the product. Using the VMWare example again, the problems they are solving are tied to companies’ inability to manage their networks today. But they have built a dependence on the presence of a functional underlying network. If the underlying network is functional, then the problem they are addressing is less acute. But if the problem exists, then the architectural foundation is poorly suited for an easy transition.
In the latter case, the go-to-market strategy needs to consider the state of the foundation. It might make sense, for example, to then partner with vendors who make the underlying issues easier. Or perhaps you target accounts where there has been recent turnover at the CIO or VP of Infrastructure level, because that might indicate a change in architectural posture. If a company is already solving the foundational problems, you could potentially draft off that effort and solve the second problem of policy management for only incrementally more cost and effort.
Whatever the path, the strategy has to reconcile that the vendor and user frames of reference are different. Adding even more innovation feels like the right thing to do (always be moving forward!), but does it widen the gap between vendor and customer to the point that transition is impossible?
Let me be clear here – I don’t actually think that NSX is necessarily at that state. I am really just trying to land the point that innovation ahead of adoption needs to be an explicit strategic discussion because it impacts how you eventually bring products to market. Again, the point is not about NSX but more about strategic consideration of the point from which users are building. If you think about innovation from a user’s perspective, you might alter your own strategies in perhaps unexpected ways.
As a final thought, as the industry continues down the SDN path, how should companies and open source organizations shape their offerings to ease adoption.
[Today’s fun fact: A hummingbird weighs less than a penny. I used to think I was like a hummingbird, but this ruins the comparison.]
Jul. 25, 2016 06:00 PM EDT Reads: 2,070
Jul. 25, 2016 06:00 PM EDT Reads: 1,407
Jul. 25, 2016 06:00 PM EDT Reads: 2,392
Jul. 25, 2016 05:30 PM EDT Reads: 736
Jul. 25, 2016 04:38 PM EDT Reads: 156
Jul. 25, 2016 04:00 PM EDT Reads: 993
Jul. 25, 2016 03:45 PM EDT Reads: 943
Jul. 25, 2016 03:30 PM EDT Reads: 1,684
Jul. 25, 2016 03:15 PM EDT Reads: 417
Jul. 25, 2016 03:00 PM EDT Reads: 1,969
Jul. 25, 2016 02:45 PM EDT Reads: 859
Jul. 25, 2016 02:30 PM EDT Reads: 866
Jul. 25, 2016 02:00 PM EDT Reads: 956
Continuous testing helps bridge the gap between developing quickly and maintaining high quality products. But to implement continuous testing, CTOs must take a strategic approach to building a testing infrastructure and toolset that empowers their team to move fast. Download our guide to laying the groundwork for a scalable continuous testing strategy.
Jul. 25, 2016 01:15 PM EDT Reads: 1,911
Early adopters of IoT viewed it mainly as a different term for machine-to-machine connectivity or M2M. This is understandable since a prerequisite for any IoT solution is the ability to collect and aggregate device data, which is most often presented in a dashboard. The problem is that viewing data in a dashboard requires a human to interpret the results and take manual action, which doesn’t scale to the needs of IoT.
Jul. 25, 2016 01:00 PM EDT Reads: 1,930