Blogs

RedMonk

Skip to content

Do Not Underestimate the Power of Convenience

Orange

The majority of large IT vendors today are oriented around traditional command and control structures. Specifically, they are optimized to build for and sell to an executive audience whose responsibilities include the selection and purchase of new technologies. In these transactions, convenience is not a primary concern, because the purchaser more often than not isn’t the user, and thus is more likely to prioritize a different set of features.

Over the last decade plus, this procurement pattern has been increasingly challenged by a variety of disruptive technology adoption models: among them Open Source Software (OSS), cloud computing, Software-as-a-Service (SaaS) and Bring-Your-Own-Device (BYOD). Developers, as we have asserted previously, are increasingly the New Kingmakers.

One of the biggest challenges for vendors built around traditional procurement patterns is their tendency to undervalue convenience. Developers, in general, respond to very different incentives than do their executive purchasing counterparts. Where organizational buyers tend to be less price sensitive and more focused on issues relating to reliability and manageability, as one example, individual developers tend to be more concerned with cost and availability – convenience, in other words. Because you are who you build for, then, enterprise IT products tend to be more secure and compliant and less convenient than developer-oriented alternatives.

In many cases, this is appropriate. Security and compliance, to pick two enterprise features, are material concerns for many organizations across a range of industries. But with developers increasingly taking an active hand in procurement, convenience is a dangerous feature to ignore. Consider the following short list of technologies owing their success in part to convenience.

  • AWS: Servers in 90 seconds via a credit card (compare to: IT provisioning speed)
  • Chef/Puppet: OSS that dramatically cuts provisioning time (compare to: proprietary IT Management alternatives)
  • Dynamic Languages: OSS, faster to learn and develop in (compare to: compiled alternatives)
  • Eclipse: OSS providing a full development environment (compare to: Borland Enterprise Studio/Visual Studio)
  • Git: OSS that enabled decentralized development (compare to: CVS/Subversion)
  • Linux: OSS that offered a free, Unix-like kernel (compare to: Windows/Solaris/AIX/HP-UX)
  • MongoDB: OSS that can be used immediately with no schema (compare to: RDBMS)
  • MySQL: OSS that was lightweight, free and simple to use (compare to: DB2/Oracle/SQL Server)
  • REST: Simple web services using existing standard protocols (compare to: WS-*)

Few if any of the above projects and services entered the world as the most impressive – let alone enterprise-ready – technologies. Many were, in fact, compromised in fundamental ways technically. What each had going for it was convenience. They were easy to get, easy to use and were either free or extremely low cost to employ on an ongoing basis. Whether by design or by accident, developers found each convenient, and most are considered developer staples today as a result.

Many vendors struggle to understand the lagging adoption of their offerings, focusing on the technical merits of their product versus the competition: it’s an industry bias. In general, they would do well to consider a wider context, one that considers the mechanics of technology adoption (related: Kohsuke Kawaguchi’s 2012 Monki Gras talk about the funnel of OSS community building) equally important to the technology itself. Examples of adoption friction:

  • Cloud services or SaaS applications that require you to talk to a salesperson or do not take credit cards
  • Free products or documentation that require users to register with contact information before download
  • Free products that are functionally limited (e.g. CPU count, node size, etc)
  • Free products that require the purchase of a separate product to function properly

None of these strategies are intrinsically bad, as long as the organizations employing them understand that they will be at a substantial disadvantage relative to competitive projects subject to none of the same restrictions. As Wikipedia administrator wrote of the Encyclopedia Britannica: “it’s hard to compete with free.” There are ways of competing, of course – data being one – but devaluing convenience is generally not a recommended approach.

Convenience does not trump all, as Matt Asay asserted, nor should it. Organizational development must balance convenience against traditional enterprise concerns. But with developers increasingly empowered within today’s enterprises (like it or not), expect that equation to be far more balanced, because for developers convenience trumps most other technology characteristics.

Categories: Cloud, Open Source.

  • http://about.me/mikeschinkel MikeSchinkel

    THANK YOU for writing this. Now I have a post I can reference when I’m trying to explain why web APIs need to be easy to use.

  • http://twitter.com/mjasay Matt Asay

    You beat me to it! http://readwrite.com/2012/12/20/cloud-convenience-checkmates-concerns 

    Of course, I was inspired by your Twitter comments, so you really beat me by a full day.  Or more. I wonder why more vendors struggle to get their brains around this.  I suspect it’s because they’re still serving the old enterprise, which still has lots of dollars to spend, but they’re missing out on the future of enterprise IT.

    • http://about.me/mikeschinkel MikeSchinkel

      Hey Matt,

      I’m on the API Craft mailing list and while the sponsors from Apigee definitely appear to get this, it appears many of the people on the list do not. They often recommend approaches that favor the inconvenient when people come to the list asking for advice. It’s almost like they view complexity as a badge of honor and believe that only “real” programmers should be entitled to use APIs.  FWIW.

      -Mike