In my recent post on IDC's 2014 predictions about how what it calls the "third platform" will radically disrupt the IT ecosystem, I note that the most intriguing prediction addresses how technology users will leverage the third platform to disrupt existing non-technology industries.
Put another way, IDC foresees that every industry will be transformed by application of mobile, cloud computing and social media technologies. In fact, it says up to one-third of the top 20 companies in every industry will be challenged as new or existing entrants use the third platform to change the pricing or processes of the industry. What this means is that companies in nontechnology industries such as auto repair will use the third platform as a weapon against competitors.
Applications
This prediction echoes the well-known 2011 Marc Andreessen Wall Street Journal editorial that proclaimed that software is eating the world. He noted how Amazon, Netflix and Pandora upended the retail, video and music industries by operating, at their heart, as software-based companies.
One might say the events of the past three years have only served to reinforce Andreessen's perspective. Today Airbnb and Uber are reshaping the lodging and taxi industries by incorporating a crowdsourcing twist to their offerings. Creating communities of users and providers, these companies threaten incumbents by coordinating information about the services without having to invest in the resources necessary to deliver the services themselves.
These businesses are asset-light and information-rich. Their growth is starting to bite: One hotel chain recently hired a CIO when it realized that Airbnb's 2013 bookings represented more than half of the total provided by this chain across all of its properties around the world. Plus, once you've used Uber or UberX, it's hard to imagine being satisfied by a standard taxi service ever again.
IDC's prediction that the third platform will disrupt nontechnology industries is dead on. What this really means, of course, is that every company in every industry has to figure out what it means to be a software company, whether it wants to use technology to improve its position or needs to use technology to protect it.
Because You'll Have to Build Software, Decide What to Build
But what does it mean to be a software company? How will IT have to change today's lengthy, manual, trouble-ticket triggered processes to support the requirements of acting like a software company?
The first thing to keep in mind is what kind of software company you want to be: An application or a component. What does this question mean?
Offering an application means you'll interact directly with the end-user and take on all the effort to build an end-user customer base, including marketing and support. Offering a component means you'll provide a service that can be leveraged by many different companies; the component provides a bit of the value the end-user receives rather than all of it. Providing a component means a much smaller customer base -- but an opportunity to be exposed to a much larger total user population than you could probably hope to attain on your own. To use a theatrical metaphor, offering a component means you're a supporting player, while offering an application means you're the lead actor.
An application would be something like Etsy, the marketplace for hand-crafted goods, while a component would be something like Twilio, which provides a REST-based VoIP telephony interface. The requirements for applications and components are quite different and offer different benefits and constraints. It's not out of the question that you will provide both -- which means you'll need to think about how you create and operations your software offerings so that you can support both requirements.
Secret to Operating as Application Provider? Continuous Deployment
I heard Etsy CTO Kellan Elliott-McCrea speak a few weeks ago about how Etsy runs its application. His presentation was fascinating:
Every customer sees a different Etsy. Even though users interact with Etsy, what each one sees is tuned to his or her particular profile. Depending on what searches have been performed, what items have been previously purchased and personal demographics, different content is aggregated to provide a "one-off Etsy" personalized for that individual.
New services and code changes implementing fixes or new functionality are constantly being deployed. There's no "update window;" instead, hundreds of changes are made each day. Etsy is a constantly evolving application, not one that infrequently moves from one version to another.
All deployment is automatic. Etsy has built an IRC-based communication system connected to its source code management system that, when triggered, deploys one or more code check-ins to the production Etsy system. This isn't, however, a matter of an individual developer checking in code and pressing a button to deploy code into production. A designated operations person decides what to deploy and when; when that individual triggers the deployment, Etsy backend systems automatically move code into the production system. No humans need to take any action.
Every deployment can be incrementally deployed and seamlessly backed out. Etsy uses a code-flagging system to identify new code and can direct traffic percentages to servers running new code to ensure it works properly. In other words, it can test a new change on a small amount of overall system traffic to ensure it works properly and, should it not do so, can easily remove the code from servers. If tested code proves that it works properly, more servers have the flag set to expose the code, increasing until all traffic accesses servers with operational new code.
Failure of an underlying services doesn't cause the overall application to stop working. The application is written so that a failed service doesn't halt the application. Instead, the application leaves that section blank or serves up placeholder information. Under no circumstances does the application stop operating due to an underlying failure. Obviously, it's not desirable that the underlying services don't work, but it's important that the higher-level application be robust in the face of service failure.
The direction of company-as-application-provider is clear: You want to serve the end-user with customized, individualized functionality that constantly evolves as new services roll out and remains robust in the face of service failure. As businesses become more accustomed to operating as digital entities, expect the pace of application changes to accelerate. This means IT has to be prepared to modify applications on an ongoing process, not an occasional "big bang."
Secret to Operating as Component Provider? Stable APIs
Providing a component, paradoxically, requires a very different approach. A component encapsulates functionality and exposes it via a RESTful API. In effect, the API represents a contract between the component provider and the user and requires a commitment on the part of the provider that the interface will change infrequently and protect the user from code changes or functionality extensions.
Supporting an API-faced service is admittedly challenging. It requires planning, technical expertise and a commitment to impose as little change as possible to API users. Certainly I've seen horrible API practices over the past few years. APIs changed overnight. Different behavior from the same provider API call when served from different data centers. APIs throttled at laughably low levels of traffic.
It's vital to understand that, as an API provider, you're responsible to users -- many of whom you may not even be aware of -- to provide a scalable, robust, reliable service. It's also vital to understand that, if you fail to provide an API with those characteristics, you may alienate or lose users -- some of whom may be anonymous but in fact represent very large companies.
Keep these critical things in mind when providing a service component:
Users depend on the stability of your API and its functionality. While you may follow Etsy-like best practices, they may not -- which means their application may stop working if your service fails. If someone's application stops working, that's probably not the best time to tell them about application composition best practices.
It's critical that your API change infrequently, with plenty of notice, and provide some period of backward compatibility. If you change the way you implement functionality, such as modifying or improving the code), the behavior of your API must not change. Moreover, as you add new functionality, expose it via additional APIs or via functionality that's exposed inside the existing API while leaving previous API functionality undisturbed.
You may not, and in fact probably will not, know the users of your API. This is particularly true if someone encapsulates your service within their service. Their user, in effect, becomes your user. The spread of mobile apps exacerbates this user anonymity and makes API stability even more important, because user populations can be so much larger.
You need to be able to support much larger user loads than you might envision when designing your component or predicting use patterns. All it takes is someone putting your API into a hot consumer application and, all of a sudden, you have massive traffic. Scalability and management are critical. Fortunately, cloud computing is available to support the former, and a number of API management products and services can address the latter.
Throttle responsibly. It's a fact of life that you'll need to throttle traffic in the face of DDoS attacks. However, understand that you can experience significant traffic from a single source that represents real users or a real use case, not an attack.
One of the funniest and saddest responses to this type of situation came when a company that shall go nameless throttled calls to its API and, when asked, asserted that the API was receiving "dozens of calls per second, each of which requires a custom XML response string." They viewed that as an unacceptable amount of traffic, betraying a limited understanding of real-world requirements for a service-based offering.
Plan your roadmap with its use case in mind. Keep the above constraints in mind when planning new functionality. Changing an existing API should be a last resort, not an easy way out of a design challenge.
As you can see, it's easier to talk about being a software company than actually be a software company. One well-known technical analyst tells me that his firm has many enterprises engaging him to talk about how they can operate like Netflix -- with disappointment a common reaction once they learn what doing so really means.
Notwithstanding the disillusionment one confronts when considering such significant changes, it's clear that they will become the norm. After all, IDC has outlined the fate of those who don't change: Being part of the one-third of every industry that's disrupted by those leveraging the third platform.
Named by Wired.com as one of the 10 most influential people in cloud computing, Bernard Golden serves as vice president of strategy for ActiveState Software, an independent provider of CloudFoundry. He is the author of four books on virtualization and cloud computing, his most recent book being Amazon Web Services for Dummies. Learn more about him at www.bernardgolden.com.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.