You may not be aware of it, but you’re likely highly dependent on APIs, or ”application programming interfaces.” If you monitor your Twitter or Facebook accounts through a desktop or mobile device, if you scan a map to a venue that’s driven by Google Maps, if you check your flight status on your PDA, you’re benefiting from one company’s access to another company’s data set or software systems, defined and connected through an API.
Why should you care that you’re increasingly dependent on this little bits of techno protocol? Because, in part, your audiences, artists, and supporters are increasingly dependent, as well. Also, because the evolution of the Internet is closely aligned with the evolution of business. According to tech-watcher Robert Scoble:
Web 1994 was the ”get me a domain and a page” era.
Web 2000 was the ”make my page(s) interactive and put people on it” era.
Web 2010 is the ”get rid of pages and glue APIs and people together” era.
While the web experience used to be about individual pages and databases, accessible through Google search, the emerging experience is much more interconnected. What appear to be separate web pages and software programs are actually aggregations of multiple systems from multiple providers. And the next wave of web and mobile support will increasingly tie these tendrils together.
In fact, while we’re fond of saying ”there’s an app for that,” the reality is more often that there’s an ”interface to an API for that.” Much less catchy, I’ll admit, but an important distinction.
Again, why is this essential knowledge for arts and cultural managers? Because time- and place-based information is increasingly delivered through APIs, and consumers will increasingly expect to find what they’re looking for through these connections rather than through Google and individual web pages.
Want to go to a movie? You don’t need to go to movietickets.com if your system can access their API. Want to reserve a table at a nearby restaurant for after the movie? You don’t need to go to a restaurant website, or even OpenTable, if your personal digital assistant can be quietly searching, selecting, and reserving while you’re watching the film. Want, instead, to catch a live performance? Forget Google or the local arts web portal. Your system can grab data and book tickets through the APIs of Eventful or Livekick or a dozen other event systems. Better yet, since these systems can also link into the API of your Pandora radio stream or last.fm accounts, it can alert you to local events you’ll probably enjoy (and can share your interest with your friends through the APIs for Twitter or Facebook or LinkedIn).
You get the picture.
You’ll still need a web home in this evolving era. And you’ll still need a calendar somewhere on that web home (at least an embedded one through an API). But expect an increasing amount of business with your audiences, artists, and colleagues to be defined and delivered through someone else’s API.
Also, the rise of the API is more evidence that hoarding, controlling, or constraining essential access to your organization is a strategic blunder. If your calendar only lives on your system, on your web site, and for your direct visitors, it will turn into a ghost town. If your ticketing is limited to your box office, your phone staff, or even a single provider, you’ll be making it harder for audiences to buy.
NOTE: As a bit of irony, the Twitter API was broken when I posted this entry…proving that a more interconnected universe also makes us more vulnerable to other systems’ problems.