As I mentioned in my inaugural column, I work for Microsoft where I'm building a community calendar system on the Azure cloud platform. Like other calendar systems, mine (obviously) runs in the cloud. But unlike other systems, mine isn't a database that users dump information into. Rather, it's a hub that coordinates flows of data from users' own cloud-based services.
I want everyone who is the authoritative source for some stream of data to actually be the authoritative source. If you are sponsoring a church supper on Saturday, I want you to record the details of that event once, in your church's own cloud-based calendar service, in a way that enables the information to appear on your site and also syndicate into other contexts: the local newspaper's website, a hyperlocal blog, the chamber of commerce site. The syndication hub that my service provides (for any city or town) enables these kinds of sites to gather, merge, and display calendar events from the church, the schools, downtown merchants, the hospital, sports leagues, the jazz club, the library, and other sources.
When I explain the model, everyone gets it.
"So I just record the information once?"
"Yup."
"And then I don't have to go to the newspaper's site, and the chamber of commerce site, and other places, and retype the information, because they can get it automatically?"
"Right."
"And if I change the time, those other sites will automatically get updated with the new time?"
"Exactly."
What's unclear, though, is how to make this magic happen. People think it requires expensive heavy lifting by IT pros. It doesn't. The solution is so laughably simple that almost nobody sees it. Just use an ordinary calendar application, one that you may in fact already use, like Google Calendar or Hotmail Calendar. Everyone understands that these applications are convenient to use because they run in the browser. Almost nobody gets this corollary: because these apps run in the cloud, you don't need to manually export data from them and send it to other people who will manually import (or worse, retype) the data. Those other people's computers -- smartphones, PCs, or virtual machines running in the cloud -- can subscribe to the data feeds provided by your cloud-based calendar.
When I try to explain this idea I run into a couple of conceptual hurdles. First is the notion of a data feed. In this case, that means a URL that responds with data in iCalendar format, which is the long-established standard way to exchange calendar data. An alarmingly large percentage of otherwise well-educated and intelligent people have never been taught what such standards are and why they matter. "We publish Weekly.PDF on the website," a high school principal told me, "isn't that good enough?" No, and neither are the smartly designed web pages that so many organizations have paid developers to create. Those web pages represent calendar information for human use, but with respect to data syndication they are inaccessible silos. As are the web pages produced by the calendar modules included with many if not most content management systems. (Yes, I'm looking at you, Constant Contact, among many others.)
Somehow we need to teach people that a canonical source of data can, and should, have multiple representations. The web page is for people to view and interact with your calendar. The iCalendar feed is for computers to syndicate your calendar. I focus on Google Calendar and Hotmail Calendar because these apps meet both needs. When you share a public calendar, they give you some HTML code that you can use to embed a human-readable representation on your website. And they also give you an iCalendar URL that provides the corresponding machine-readable data feed.
The notion that the URL points to a data feed is another major conceptual hurdle. If you need something from me, a million years of evolution taught us how that must work. I hand it over to you. If I also need the thing that you need, then I make a copy, hand over the copy, and keep the original. When the thing in question is a chunk of information we reify it as an exchangeable object: a piece of paper, an email attachment. That's the physics of the real world.
In the virtual realm, though, different laws of physics apply. I can simply refer to the thing you need. I hand you the reference instead of the thing, I still have the thing, you have it too, and we only need to do that transaction once. Thereafter when I change the thing, you have my changes too, no need for me to send another fax or email attachment. The principles at work here -- indirection, linking, automatic data exchange -- are inherent to cloud-based systems. Computer programmers and information scientists realize that, but it's still far from obvious to most other people.
I want to use the humble example of a church supper -- recorded in Google Calendar or Hotmail Calendar, published on a website, and syndicated to other sites -- to illustrate a general idea about personal (and organizational) clouds. They can, or anyway should, be active participants in an ecosystem of data exchange that puts everybody in control of their own information and requires nobody to copy and paste it elsewhere.