High Risings

In the Hyperlinks Subvert Hierarchies chapter of The Cluetrain Manifesto, David Weinberger writes,

Somewhere along the line, we confused going to work with building a fort.

Strip away the financial jibber-jabber and the management corpo-speak, and here’s our fundamental image of business:

• It’s in an imposing office building that towers over the landscape.
• Inside is everything we need.
• And that’s good because the outside is dangerous. We are under siege by our competitors, and even by our partners and customers. Thank God for the thick, high walls!
• The king rules. If we have a wise king, we prosper.
• The king has a court. The dukes, viscounts, and other luminaries each receive their authority from the king. (The king even countenances an official fool. Within limits.)
• We each have our role, our place. If we each do the job assigned to us by the king’s minions, our fort will beat all those other stinking forts.
• And then we will have succeeded—or, thinking it’s the same thing, we will say we have “won.” We get to dance a stupid jig while chanting “Number one! Number one!”
• This fort is, at its heart, a place apart. We report there every morning and spend the next eight, ten, or twelve hours inaccessible to the “real” world. The portcullis drops not only to keep out our enemies, but to separate us from distractions such as our families. As the drawbridge goes up behind us, we become businesspeople, different enough from our normal selves that when we first bring our children to the office, they’ve been known to hide under our desk, crying.

He adds, “the true opposite of a fort isn’t an unwalled city. It’s a conversation.”²

Yet in the years since Cluetrain came out, conversation was something marketing talked about more than something whole companies actually did. This is about to change, thanks to APIs.

“Fort business won’t go away,” Craig tells me. “The corporate high-rises will still be there. On the Web, however, they will be turned inside out, so that a company’s core competencies will be exposed to the world—in ways that can be engaged directly. The means for engagement are APIs. Companies with exposed APIs are the new skyline of the Web.”³

API stands for application programming interface. Think of APIs as user interfaces for code. Most APIs on the Web today produce live feeds of data on request by other sites and services. Take, for example, the Google, Bing, and Yahoo maps that appear on a Web site or a smartphone app. When you search for a restaurant on Yelp and it shows you a Google map, Yelp has obtained that map through a request to the Google API, which responded with the required map. This is why Google, Bing and Yahoo are already big on the Web’s skyline.

APIs such as these, however, are not yet fully evolved in the direction that Craig sees as the Live Web end-state. They are teats on the cows of dominant Web services, providing milk for the calves of dependent ones. (See chapter 3 for more on the calf-cow model.) Turn those cows upside down and make a skyline of their teats, and the two metaphors make a fun kind of sense together. But even upside-down, this API convention is still hierarchical, still calf-cow. That’s a problem, because hierarchies are trees that don’t grow to the sky.

The Network City

Commenting on the city model, Kynetx founder and CTO Phil Windley writes:

I think there’s more than a mere metaphor between the city/corporation insights and the ways we build software today. I’d argue that social systems, including cities, are models for the techniques and technologies we ought to be using. Networked systems scale better and are more flexible than hierarchical systems. They can absorb complexity better without suffering from the debilitating effects of tight coupling that hierarchical systems create. But I’m ready to go farther …

While API-based systems are more flexible than the moribund systems that enterprise IT shops create, they don’t go far enough. They are still request-response based. Request-response based systems are hierarchical and create unnecessary coupling. Cities and other social systems do not operate solely using a request-response model. The dual of request-response is events. Event-driven systems exhibit more of the network architecture that makes cities flexible and robust.⁴

So Phil and his team at Kynetx created the first spec for evented APIs. Evented APIs are not request-response, which is half-duplex (only one way at a time, taking turns), but conversational, and full-duplex (both ways at once, like a phone call). That way they can interactively listen, carry out orders, and obey rules that you write, or that you have written for you—say, by your fourth party.

Phil has made this easy with a language called KRL (kynetx rules language), and a rules engine for executing the rules. Both are open source. Together, they help create the Live Web (also the title of Phil’s new book).

As Phil puts it, “KRL allows you to treat every API, and every app on your computer or phone, as social products and services that work with you and for you in the urban environment of the Live Web.” For the first time, “social” is something you do, outside of any one company’s silo. No one company, including Phil’s, owns or controls your social context in any way. Whatever you want can be social with whatever else you want.

“This is like what has been called the Internet of Things,” Phil says, “only more personal—in fact intensely personal. Your personal event network forms your own personal cloud where apps under your control interact with your personal data, services you use, and products you own, to accomplish the things that are important to you, freeing you from the tedious and mundane interactions that are still business-as-usual on the Static Web.”⁵

When I asked Phil to draw his own personal cloud, he e-mailed it to me (see figure 22-1).

FIGURE 22-1

Phil’s personal cloud

On the outside of the figure:

• Things, including bathroom scale, thermostat, fridge, sprinkler system, car, GPS, TiVo, and exercise gear⁶
• Company APIs, including a calendar, a travel service, company CRM system, and credit card company

On the inside are apps that can interact with all the APIs on the outside.

There are no limits to the variety of what goes inside or outside. You’re the boss. Put whatever you want inside and interact with whatever you want on the outside. If neither is ready for you yet, don’t worry. It will be. The upsides to participation far exceed the downside risks of exposure or whatever else companies making APIs or apps might worry about.

In Any Event

KRL lets you mash up contexts from any variety of relationships you already have. It also lets you create new ones. Let’s look at what it can do, starting with the simple and working up to the complex.

A trivial but fun example is what I’m looking at right now on Twitter (see figure 22-2).

FIGURE 22-2

KRL relationships

See those little numbers next to the handles of @jeffsonstein, @matclayton, and @stevegarfield? Twitter didn’t put those there. Nor did PeerIndex, which supplied the numbers (which it calls a “relative measure of your online authority”). I put them there, using a free browser plug-in from Kynetx called HoverMe. That plug-in calls out to the PeerIndex API, obtains the little numbers, and puts them next to each tweeter’s @-handle.

For even a casual programmer, writing plug-ins like HoverMe using KRL is easy. So are writing other programs to do just about anything, mostly by taking advantage of exposed competencies, not just of businesses and organizations, but of each individual.

That’s why we’ll have our own live and evented APIs as well. Markets will be conversations, not just for us, but for every device, app, and service we use. We will have our own ways of exposing our own core competencies, and we will be in full control of them.

Now for our next hack: adding local Best Buy results to Amazon searches on the Web. Here’s how the logic works:

1. If the item I’ve found at Amazon is also available at Best Buy,
2. And the item is in stock at the nearest Best Buy,
3. Then I see the price for the item at my nearest Best Buy, along with other helpful information, such as how far away that Best Buy is.

I have that hack, done with KRL, in my Chrome browser, right now. Here’s a key thing: neither Amazon nor Best Buy is involved. I’m the one doing the shopping, and I’m the one with the rules that make Best Buy results appear in my Amazon search. The hack was done in KRL in just a few minutes, and it has been handy for me ever since.

Now for the complex scenario, involving a salesman we’ll call Bob, who works for a company we’ll call BigCo. Bob lives in Denver and is going on an overnight business trip to see a client in San Francisco.

Bob’s personal cloud (like Phil’s) has these apps on the inside:

• TripEase (which doesn’t exist yet, but something like it will)
• Calendar
• Expensify
• OpenTable
• TomTom
• Quickbooks
• Singly

The APIs on the outside are the exposed competencies of:

• Marriott
• United Airlines
• Avis
• Visa
• Salesforce

We start as Bob confirms an onsite visit with his San Francisco client. When Bob schedules the meeting in his calendar, an appointment event is sent to his personal cloud. Evented applications and services Bob uses are listening for these events and respond by taking action on Bob’s behalf. In this case, Salesforce fills out appointment details in his calendar, such as Bob’s client’s office location and directions for parking nearby.

Meanwhile, rules in Bob’s TripEase app react to the same event, recognize the appointment is in San Francisco and that Bob will need travel arranged. TripEase knows Bob’s travel preferences (e.g., a single room at a Marriott hotel, a compact car from Avis, an aisle seat on United, and a request to United for an upgrade to business class if a seat is available) and marks available choices from each on his calendar. TripEase also knows that Bob has memberships in loyalty programs with each of those companies and also with other companies, in case Bob’s first-choice preferences aren’t available. Bob sees the choices, makes them, and TripEase puts those in the Calendar.

In the background, TripEase also raises a new business trip event, causing Expensify to bring up an expense journal, so an accounting of expenses can be made at the end of the trip. So, when Bob gets to the airport and buys a sandwich with his Visa card, Expensify automatically adds that purchase to this trip’s expense journal. And, because Expensify and TripEase are cooperating, Expensify has more context for purchases and can make better categorization decisions without Bob’s involvement.

After landing in San Francisco, Bob turns on his smartphone, and its location function raises an event indicating Bob is now at SFO. Avis hears and responds to Bob’s location event by preparing Bob’s preferred car and paperwork. To help with that, TripEase also lets Avis know that Bob will decline Avis’s insurance offer and return the car with a full tank of gas. If Avis does not already have this information, TripEase fills Avis in on the facts, and auto-signs Avis’s agreement, so Bob doesn’t have to bother with that. TripEase also puts Bob’s appointment destination in the TomTom app on Bob’s smartphone. After meeting with his client, Bob drives to the Marriott and parks there. When he arrives at the reception desk, he is greeted by name and given his preferred room (on the north side of a high floor) and a key to his room and the exercise facility. He also receives a notification from Open Table that two of his favorite restaurants have reservations available. He decides on one and proceeds to his room. Open Table also sends an e-mail and a text to his client with reservation information.

All these connections are made in the background, on Bob’s behalf, by apps and services that he or his fourth party have already programmed, using KRL.

After checking out of the hotel (automatically, of course), driving his car back to Avis at SFO, flying back to Denver, and driving back to his house, TomTom tells TripEase that Bob has completed the trip and raises an end-of-trip event. Expensify sees the event and moves Bob’s journaled expenses—air fare, hotel, rental car, gas purchases, dinner, personal driving mileage (to and from the airport), and parking fees—from his trip journal to his expense report. After reviewing and approving the report, Bob tells Expensify to send it to BigCo’s Salesforce system, which is in the cloud Salesforce keeps for BigCo.

Expensify has also sent copies of expenses to Bob’s own personal cloud, which comprises these:

1. His personal data store (PDS), which is where he keeps his personal data, fed from many sources, including all the apps and services mentioned. While Bob could keep his PDS on a self-hosted server, his preference is to use Singly, a fourth-party he pays to keep his data and relationships sorted out, secure, and up to date. Singly also has a rules engine he can use, but he isn’t limited to that one alone.
2. His personal API. This can live anywhere, but would most likely live with his PDS.
3. His rules, written in KRL.
4. His memorandum book.
5. His journal and ledger, kept by QuickBooks.

His memorandum book is the modern version of what for centuries was the first step in double-entry bookkeeping: the place where everything that happens is first written down. This helps Bob (and his tax preparer) remember what happened when, as well as what it cost.⁷ From there, it goes to his journal and then to his ledger, which can generate the usual reports. Meanwhile, he has an accountable and auditable trail of records.

To be fair to everybody else in this future game, KRL won’t be the only way to do what I just described. It’s just the one I know best today, because Phil and his colleagues at Kynetx have been highly involved in the VRM tool development community. So have some of the other companies I’ve mentioned.

The Troika

Craig Burton knows ubiquity. I watched him make it happen with Novell in the 1980s, and I’ve watched him teach how it works, over and over again.

He points out that by late 2011, there were a few thousand APIs in existence: a town, not a city. Still, there is a hockey-stick shape to the growth curve. This will continue upward until it flattens at ubiquity, which will be the sum of everything that can have an evented API, including every individual with a mobile device. Says Craig,

There are three core things that make the Intention Economy start to work, and grow toward ubiquity. Call it a troika. They are:

 

1. Cloud-based code (code platforms like Kynetx that are API- and cloud-centric).
2. Cheap telephony-data (affordable mobile-telephony data pricing like Ting.com provides).
3. Personal data technology (cloud-based stores that are controlled by the individual. Singly is promising such a thing, Cloudmine.me has one up in beta).⁸

That’s for both companies and customers. For companies specifically, he adds, “Get with it. Figure out your API strategy. Understand the API Economy Troika and how it relates to what you are doing.” And, be a ubiquitineur, which he defines as, “An entrepreneur whose business and innovation practices are ubiquity-based as opposed to scarcity-based.”⁹

In other words, build in the Live Web and not just the static one.