The Changing World of Vendor and Provider Relationships

This past week, Mary Meeker published her amazing annual look at technology trends and the state of the web. As usual, it provides great details around macro-level trends effecting usage, devices, economics and much more. And the highlight is her "Re-Imagination - of Nearly Everything" section, looking at how innovation and software are rapidly changing nearly every element of our daily existence.

While this absolutely applies to services and devices, it also applies to the rules surrounding technology vendors and services providers. In the past, vendors employed 1000s of engineered and delivered HW and SW capabilities to customers and service providers. In many cases the customers or service providers built custom automation (eg. scripts) or management software, but few built their own custom hardware, operational software or APIs. But all of the old rules of engagement and creation are changing, and changing rapidly.

For many years, we've seen technology vendors buy Software-as-a-Service (SaaS) companies to expand their portfolio (eg. WebEx, Boomi). Other technology vendors have launched their own SaaS services (Microsoft 365, SAP OnDemand, Oracle On Demand, VMware SlideRocket).

But the new rules are getting very complicated.

New Community Interactions for Hardware Vendors

[Disclosure - My employer is EMC]

A few weeks ago, my good friend Nick Weaver (@lynxbat) released "Project Razor" in conjunction with EMC and Puppet Labs. It's a framework to simplify the deployment and automation of bare-metal or virtualized server environments, bringing more of the stack into a DevOps models. While I'm biased and think the code is pretty awesome, the more interesting aspect is that a major hardware company (EMC) was part of an open-source project.

As Dan Hushon (Distinguished Engineer, EMC) stated during our podcast prior to the release, this isn't the first time EMC has contributed to an open-source effort (he mentioned contributions to NFS), but it is the first time they've given so broadly to an open-community and with a partner like Puppet Labs.

This isn't about EMC, but rather hardware vendors (in general) trying to adapt to a changing world where software is driving more and more value. Let's take a look at three different (recent) approaches taken by traditional hardware vendors are they engage around software-centric projects.

SDN is Marketing to Wants, not Needs

There have been plenty of articles written about how Software Defined Networks (SDN) don't really solve a specific use-case that couldn't (actually or potentially) be solved with networking solutions that exist on the market today.  These are typically written by people that either have a vested interest in existing models of networking (eg. hardware vendors) or consultants that have existing projects and architectures in place (eg. complexity extends the contract). But what you don't often see is articles written by users (or "customers") that are clamoring for more of the same. When those groups show up at public forums or events, you almost always hear them talking about how they want their network to operate.

• They want less complexity in deploying policies
• They want less complexity in managing upgrades to 100s or 1000s of devices
• They want new flexibility in detailing with complex situations like "BYOD" (or "CoIT", or whatever you can it when users want to bring in their iPad to work)

[NOTE: There are several other wants that are frequently mentioned; buy commodity hardware, invented new routing protocols, etc.. but they are typically the domain of the largest web operators, not on the immediate wish-list of Enterprise or Mid-Sized companies for the next 3-5 years]

Part of the reason you don't hear "the killer use-case" coming forward is because that isn't the overwhelming want. And as much as people can debate wants vs. needs, the reality is that with new things wants are often the driving force. When people make the choice to try something new, they typically don't do it so they can extend the past. 

So be careful when looking at SDN. The earliest adopters might not be looking to change because of an unmet need, but rather because of an unmet want.