"Cloud" has a special place in my hit parade of despised neo-techno-vernacular. Unlike Web 2.0, my all-time favorite, at least "cloud" is somewhat self-descriptive: Formless, vaporous, and a semi-reliable indicator of climatic conditions. If you point at a round, puffy cloud and declare that it looks like a pitchfork, and someone with you nods and says, "Cool, I can see that," the forecast is mostly patronizing with zero vision and periodic sucking up. You're in trustworthy company if that person says, "Are you blind?" If someone in a meeting refers to a cloud, or worse still, the cloud, don't nod just to keep the conversation going. Consider it your duty to ask them to define the term.
Whenever I can, I tackle buzzwords head on by unilaterally issuing a concrete definition. I've decided that a cloud is a hosted data store equipped with omniscience and omnipresence, aware of every movement and able to land anything from a stream to a droplet of data on a moving target with faultless precision and efficiency. A cloud assures guaranteed intact delivery of arbitrary payloads, autonomous, simultaneous, and network-agnostic synchronization of an unlimited number of clients, immediate sensing of a client's presence after a period of non-availability, real-time notification of new data, intelligent handling of fragmented and out-of-order payloads, optimal use of low-speed and unreliable connections, continuous retry persistence, periodic reports of delivery failures, and end-to-end acknowledgement of successful delivery.
When I send information to this cloud I've defined from my desktop or mobile device, either explicitly by sending e-mail or implicitly by making a change to my schedule, I get a real-time acknowledgement that the cloud has received the data. I can then take for granted that the cloud will blanket the globe to find all client devices interested in that information, push the data to them simultaneously, and verify that it reached them intact. If the cloud can't locate a client, it obsesses until that client pops up on radar. When it does, the cloud assumes that connectivity to the client is fickle and fragile (with mobile connections, it often is). It hurriedly delivers at least a fragment of everything in the queue, because if I'm only in sight of the cloud for a few seconds, I'd rather see the first 50 words of all the messages waiting for me than one message with a 1MB attachment, and nothing else until that message is fully transferred. It takes a cloud to do that.
If someone tries to sell you a cloud that doesn't meet most or all of these requirements, tell them for me that they'll have to call it something else. If someone designs a cloud to my specifications, tell them that I screwed up their shot at a patent.
I haven't seen anything meeting that description made available to commercial users as a packaged service from anyone but RIM. The BlackBerry delivery, presence, and notification infrastructure is not regarded by its users to be a cloud. It's just BlackBerry; the capabilities of the infrastructure define the device. A BlackBerry handset is a proprietary terminal for a commercial cloud. Take away RIM's cloud, and a BlackBerry becomes a PDA with a very slow browser.
RIM's cloud is heavy on immediate notification and reliable delivery of short messages and light on services. Even though every BlackBerry has calendar and contacts applications, they are only synchronized over the air if you have an in-house or hosted back end with BlackBerry Enterprise Server (BES) plus Exchange, GroupWise, or Domino/Notes. BES enriches RIM's cloud by letting other data and notifications hitch a ride on it. Oh, go up and add extensibility to my definition of "cloud." I didn't put it in because I take for granted that any commercial-grade solution is extensible via published APIs and protocols.