Category Archives: API

…Decomposing Businesses Into Services…

What kinds of services should hyperbusinesses offer through interfaces? This question can be a bit of a stumbling block for businesspeople still somewhat new to the transition to hyperbusiness. Nearly every business can be ‘disaggregated’, broken apart into a set of discrete and independent service offerings. This doesn’t involve a radical change to a business model, rather, it’s a way of rethinking the existing business.

Take, for example, the hotel room where I type these words. I’m in a room at the Mandarin Oriental Bangkok, considered to be one of the finest hotels in the world. Certainly the level of service and attention to detail place this establishment into the very highest ranks of luxury hotels. But what is it, exactly that I am paying for? What services are the hotel providing to me in return for my daily rate?

Here’s a list, which is not meant to be utterly exhaustive, but gives an idea of what a business looks like when decomposed into services:

  • Room rental (50 m2 overlooking the Chao Praya river)
  • Furnishings rental (bed, desk, chairs, carpeting, art, etc.)
  • Bathroom toiletries & linen
  • Electricity
  • Air conditioning (vital in Bangkok’s tropical weather)
  • Water (both bottled and on tap, hot & cold)
  • Tea service (kettle and tea selection)
  • Television and satellite reception
  • Telephone
  • Housekeeping
  • Personal butler
  • Concierge
  • Ferry service (it’s quicker to move by river in Bangkok than by car)
  • Swimming Pool, Gym, Jogging track, Tennis courts
  • Newspaper

I do pay for each of these services, and the hotel certainly knows its cost to deliver each of these services. Even though this bundle of services has been presented as a single, unified service offering, it is really a composite of many services, each of which could be offered individually, or combined together in any appropriate bundle.

In addition to these services, there are a number of services that I can choose to subscribe to, but which are not aggregated into my daily room rate:

  • Minibar
  • Room service
  • Massage & spa treatments
  • Airport limousine service
  • Dining in hotel restaurants
  • Drinks from hotel bars
  • Thai cooking school
  • Day care for the kids
  • Internet connectivity
  • Thai cultural programme

If the Mandarin Oriental Bangkok wanted, it could decompose my bill into a series of individual service offerings, letting me choose which services I wanted, paying only for those, but the packaging of these services into a daily room rate makes it easy for all concerned, particularly the accounting department, which would have to keep track of all of these service subscriptions for each guest — something not very difficult in the age of computers and networks, but nearly impossible just a generation ago.

If someone wanted to create a hotel that offered all of its services like this – entirely ‘a la carte’ pricing, you could imagine some interesting configurations: long-term residents might provide their own furniture, but subscribe to housekeeping services; short-term residents might take the room and furnishings but clean the room themselves to save some pennies, and so on. A few hotel chains – such as Malaysia’s Tune Hotels, where you pay extra for television, air conditioning, fresh bathroom linens, etc. – have already begun to decompose their service offerings like this, a bit like ultra-low-cost airlines, which charge you for every bag, every extra inch of legroom, and every drink. Now that it is possible, service decomposition has become the hallmark of hyperbusiness.

These decompositions are more than theoretical exercises. A well-planned and implemented decomposition activates value latent within an organization. Jeff Bezos, the founder and visionary behind Amazon.com, wrote a detailed memorandum to Amazon’s employees, instructing them to disaggregate the entire business. Every service Amazon provided had to be presented through a service framework – an API. (Bezos closed the memo by warning anyone who didn’t fall in line behind this strategy that they were already fired.)

As Amazon began the process of decomposition, the online retailer’s massive computing infrastructure – used to power its customer-facing retail division – stood out as a potential service offering. Amazon had much more capacity than it needed, in order to manage the huge traffic rush during the Christmas shopping season. Most of the year that capacity lay dormant, underutilized – while still sucking up electricity, cooling, and space within Amazon’s data centers.

Broken out as a disaggregated service, it became possible to offer that immense network of computers and storage to businesses that wanted inexpensive, reliable and scaleable computer services. A customer could subscribe to a single computer’s worth of processing power, but, if the customer’s needs suddenly changed, they could immediately and elastically expand the amount of computer power they rented from Amazon. It can all be managed through interfaces, so the computers themselves could decide to add more capacity when they sensed they were becoming overloaded, or shrink that capacity when they spent too much time idling.

This product – Amazon Web Services – touched off a revolution now known as ‘cloud computing’. Many of the Internet’s biggest business, from Twitter to Instagram to Dropbox, use Amazon Web Services because Amazon has already done all of the capacity building those businesses would otherwise need to do for themselves – with corresponding capital and human resources requirements. Instead of building a data center and staffing it 24/7 with anxious nerds, it’s possible for anyone to simply pay Amazon a rental fee, and have access to the same resilient network of computers which make Amazon’s website one of the most stable on the Web.

The biggest user of Amazon Web Services is the Netflix entertainment service, which streams movies and television shows to a compatible televisions, videogame consoles, computers, tablets, and mobiles. Netflix has proven incredibly popular – it’s estimated that as much as a third of all Internet traffic in the United States after 8 pm local time is Netflix streams!

Amazon also offers a streaming entertainment service – a direct competitor to Netflix – also running atop Amazon Web Services. Here’s an idea at the heart of a hyperbusiness: Amazon is enabling one of its competitors with one of its own service offerings. That’s nothing to be afraid of. In fact, it should be embraced. It is the ultimate validation of a hyperbusiness’ service offering when a competitor chooses to use it.

Amazon may not win in the streaming entertainment business, but they’ll still be making plenty of money, supporting Netflix – and every other company that wants to compete with Netflix without spending tens of millions of dollars on a data center. Amazon Web Services has become the de facto standard for cloud computing, and Amazon has gone from being merely an online retailer to a technology company providing the support for a significant portion of the Internet. That’s the kind of latent value that gets released within a successful service decomposition.

Hyperbusiness Opportunity #4

photo: cgt

One of the most successful APIs in use on the Internet today belongs to Twitter. Despite its overwhelming success – and half a billion users – Twitter has struggled into profitability. The service can be used freely by anyone, for anything imaginable – but that doesn’t create revenue for Twitter. CEO Dick Costolo has decided on a change of direction, restricting the API in an effort to channel Twitter’s users toward Twitter-created tools showing Twitter-approved views — delivered with embedded, unblockable advertising.

It’s a tricky thing to change an API that millions of developers have been using for years. Many of Microsoft’s APIs for its Windows operating system have remained essentially unchanged for almost two decades, precisely because the software giant did not want to force programmers to re-write their programs – and risk losing them to a competing operating system. Most often companies will ‘deprecate’ their APIs, essentially saying, “We’d prefer you didn’t use this, but if you really must, here it is,” keeping them available for years while guiding programmers through a relatively painless transition into the new API – that’s Apple’s strategy.

In order to satisfy its commercial imperatives, Twitter will remove services, not simply obsolete and replace them. Some things a developer can do with Twitter today will not be possible in the near future. Their applications will break, and no amount of rewriting will restore that functionality.

Twitter has become an Internet-on-top-of-the-Internet, a way of making connections through an abstract interface which removes the requirement of knowing where the connection is being made. Although we rarely reflect upon it, the Internet is very much like a landline telephone network – an Internet Protocol (IP) address is attached to a specific computer in a specific place. This is glossed a little for mobile devices, which have temporary IP numbers assigned to them as needed, but the idea remains the same: the number maps onto a computing device.

Twitter changed that; I could be on any computer anywhere, and, via Twitter’s switchboard messaging, could engage in communication with another computer (and user) anywhere, neither side possessing any awareness of the location the other. All you need is the Twitter account ‘handle’ – such as @mpesce, @TheEconomist, or @servalproject – to directly connect to the other party. This is an important service, one for which there is great demand. If Twitter will not provide this service, another organization will rise up to meet that need.

Software developer App.Net recently raised half a million dollars through crowdfunding to provide such a service. When they started their fundraising, Twitter had not announced its change in direction, but their timing was excellent – as soon as the announcement came, contributors flocked to App.Net, knowing they would need a reliable provider, serving up an API providing the abstract connections that has made Twitter so powerful.

Twitter seems perfectly content to cede this ground, choosing short-term profits over long-term utility, casting itself as an application, rather than the plumbing that makes many applications possible. There may be no glory in plumbing, but people will always need it; plumbing opens the path to opportunities inconceivable for an advertising business.

…Accessible Via Interfaces…

The street finds its own uses for things — uses the manufacturer never intended…
— William Gibson

A growing number of frameworks have been put to work to create markets for services and products where none existed before. While it’s necessary to have that framework in place, a framework alone does not guarantee that a market will form. The framework has to be accessible. People need to be able to use it. Often the framework becomes the backbone of an app or a website. Uber, for example, uses its smartphone apps to present two different views into its transportation framework, one suitable for drivers, the other for passengers.

Though apps can create markets, they also limit the potential of that market. An app is a highly specific view into a market which rigidly restricts possibilities. To order up a limousine from Uber, you must launch the app. But the service – a driver, on-demand – is broadly useful. It could be used by people in ways Uber never imagined, ways that have nothing to do with a smartphone app. Uber aggregated drivers and passengers using their apps, but those apps become a cage that limits growth.

One company that understood the limitations of apps is the messaging service Twitter. Twitter began as a service for sending short messages – ‘tweets’ – to everyone interested in your activities. This service provided a framework for communication between Twitter’s hundreds of millions of members. Additionally, Twitter released an ‘Application Programming Interface’ – or API – providing similar functionality to that found on the website. The API specifies a series of commands – ‘send a tweet’, ‘read a tweet’, and so forth – that everyone must use to interact with Twitter, including Twitter itself.

This API makes it possible for anyone to use Twitter for their own purposes. Major news organizations, like the New York Times, publicise their stories on Twitter: as a story goes live, computers at the Times use Twitter’s API to send out an automatically-generated tweet. Many systems now embed Twitter in their architecture – Apple’s own iOS, the operating system for its iPhones and iPads, has Twitter built into its basic components, so any iOS app can send tweets.

This open interface to Twitter created a lot of competition for the best interface to Twitter. In fact, there is no one right interface – different people and different industries have different needs. A profusion of interfaces means that everyone gets exactly the Twitter experience they can best benefit from. Twitter gets more users – half a billion and counting – without having to cater to the needs of each user – the users themselves see to that.

Twitter gets used in many applications its creators never envisaged. When a computer program experiences an error in its operations, it can send a Tweet to alert a human to the problem. Computers can even talk to one another, using Twitter as a sort of post office or central dispatcher. One individual even created a belt to be worn by heavily pregnant women – every time the baby kicks, the belt sends a tweet!

Interfaces greatly amplify the utility of any service. Twitter would still be a tiny messaging service, dwarfed by Facebook and ignored by everyone else, if not for the million and a half applications that use its API. Instead, Twitter has become an essential utility, used by journalists, politicians, and businesses around the world, precisely because of all of those applications. The firm’s success is built atop the efforts of hundreds of thousands of developers who used Twitter’s API to solve their own problems.

Imagine what might happen if Uber created an API to its service, encouraging others to use it in their own businesses. Anyone would be able to provide an on-demand limousine service. A nightclub might offer that service to tipsy patrons through a specially-branded app. A restaurant could add it into their reservations system, as could a hotel, or airline, or car rental company. As the opportunities to use Uber multiplied, Uber’s business would grow dramatically. Uber would become the default solution for transportation.

Interfaces benefit every hyperbusiness framework. Postmates has recently launched a San Francisco-based delivery service, ferrying items (generally restaurant and cafe orders, but it can be pretty much anything) from one point to another in less than an hour. The service is proving successful, but currently is only accessible through a smartphone app. (Sound familiar?) If Postmates offered an API, any business in San Francisco that wants to offer a delivery service could use that API to provide a delivery service for their customers. When that happens – and it surely will – Postmates will suddenly become the most obvious way to deliver something. Everyone will be doing it.

Product-oriented business also benefit from interfaces; in many cases there’s no reason to go through a human to order something. Amazon.com doesn’t have any human order-takers, but they’re now one of the largest retailers in the world. The interface is the new sales channel, whether you’re selling a product or a service. Now that markets are everywhere, aggregating everything, interfaces are the glue between frameworks and the people who want to participate in a market. Interfaces marry demand to opportunity, because an interface creates more possibilities for the market to become pervasively accessible – like Twitter.

This is the first law of hyperbusiness: Create an interface to your framework, or face irrelevance. People gravitate to the best interfaces: one of the reasons MySpace lost out to Facebook was that Facebook created a powerful API that fostered the creation of an ‘ecosystem’ of Facebook Apps. Using that API, companies like Zynga built themselves into huge businesses, within Facebook. MySpace did finally offer an API, but far too late, long after it had lost its commanding lead over Facebook. MySpace provided no space for anyone else, and hyperbusiness moved on.