As a follow-on to the discussion of the types of applications and services that are driving demand for presence platform software, let’s now turn our attention to the critical requirements for this new software category. If I’ve missed something that’s important to your existing or planned deployment of presence technology, please post a comment on this blog.

To be broadly useful, presence platforms must be scalable, highly available, extensible and able to work with other middleware and network services. It is worth noting that some of these requirements are the same or very similar to the requirements of more established types of platform middleware, particularly services at the edge of the network, such as Web servers and application servers. This is because presence platforms in commercial deployments have similar, and in some cases, greater demands placed on them by the enterprise applications, consumer-facing services, etc. that they support.

The ability to scale is critical because presence must, by definition, be a real-time service. In commercial applications, a presence server must scale to be able to route presence information between millions of network nodes. Millions of points of presence are not uncommon, even in traditional enterprise settings. When counting points of presence, consider that a single person, device or sensor can have multiple presence elements. For example, a person with a desktop computer, and both desktop and mobile telephones has three points of presence, not counting additional presence states of presence-enabled applications running on their computer. With millions of nodes with changing presence states, a presence platform must be able to handle extreme message rates. For example, in some benchmark testing designed to model consumer service use patterns, rates of over 15,000 messages per second were observed. Without a highly scalable presence platform, presence information degrades into pseudo real-time information - what presence was, not what it is. Latency in the delivery of presence information greatly reduces its value and may cause errors and oddities in presence-enabled applications.

As presence is an always-on service, presence platforms must be highly available. The presence platforms which meet availability requirements typically have built-in architectural redundancy and auto-healing features designed to gracefully recover from outages on the network or at the network node level.

There is no such thing as a one-size-fits-all presence model. To allow the presence platform to be tailored to specific applications and services, it must provide developers ways to access and extend its capabilities. As there are several presence protocols in general use ( e.g., SIMPLE and XMPP) support for multiple standards makes it easier for application developers to make use of a presence platform when the presence nodes speak different protocols. To maximize interoperability and prevent vendor lock-in, presence platforms should be based on truly open standards and not rely on proprietary extensions. Another important development requirement is libraries to facilitate the creation of clients and software to connect network nodes and applications with the presence platform. A diverse set of libraries, such as is listed here, represents a major advantage for a presence platform, as it allows developers to work in the language that is most appropriate for their specific objectives.

Presence platforms are not stand-alone entities. In most use cases, presence platforms must interoperate with other network software, such as directory servers and data base services. As presence is often a new service added to an existing deployment architecture, the presence platform must be able to integrate with existing network middleware. To minimize data/hosting center floorspace and management costs, presence platforms should run on the most popular server operating systems, so a customer is not required to provision new hardware and train staff on the management of a new OS.

If you have deployed a presence platform or are planning to do so, do you have other requirements?

As presence becomes integrated into many application categories, it becomes problematic to have separate presence models for each application or service. By sharing a common presence platform, applications and services can draw from a consistent, synchronized store of presence information. This common “presence pool” can be tapped to integrate applications, route communications, data and to monitor conditions in real-time. The vision of common presence platform that can be used to add presence to existing or next-generation applications is catching on. There is commentary on the topic and there are commercial presence platforms, including Jabber, Inc.’s, in the market.

The application categories where presence is valuable or essential include: Unified communications, social networks, consumer services, collaboration tools, workflow and monitoring applications. Today, most of these applications have their own, built-from-scratch presence platforms and typically can not exchange presence information with other applications.

What do you think?

• Have you, or are you considering presence-enabling existing or new applications or services?
• Do you like the concept of a common presence platform?
• Do you plan to write your own presence platform from scratch, or use one that works off-the-shelf?

Of course, here at Jabber, Inc., we’re biased towards the off-the-shelf model, but would be interested to learn why you have, or are considering writing your own presence engine from scratch.

Walled gardens have been a characteristic of presence and real-time messaging since the beginning, but the time has come for these walls to come down. Presence enjoys the benefits of network effects - the more presence nodes, the more valuable presence becomes.

How can vendors speak of interoperability yet continue to force their customers into walled presence gardens? Can you imagine unified communications systems where the telephony and email services only work within the walled garden? Federated presence, based on open standards, allows users of unified communications systems to view the presence of all of those with whom they need to communicate and to publish their presence to others. The value of presence in unified communications is greatly diminished if it is restricted to a subset of those people - those who happen to be using the same UC platform.

Mike Gotta asks some excellent questions in his report from the Microsoft Unified Communications launch:

The link to presence and identity is a really important point - and to extend that into the area of social computing is another direction to consider re: social presence not just presence as it pertains to a network, device or application (refer to my earlier post “Social Presence: We Need To Push The Reset Button“.

That said - it raises some questions:

• Why does Microsoft still not federate with Google via XMPP?
• Why does Microsoft not openly state its direction on some of the IETF-related presence standards?
• Should Microsoft take its PSOM protocol (used in its web conferencing components) and treat it as an open standard (similar to XMPP)?
• Will Microsoft openly expose its granular rich presence information in a bi-directional manner to other vendors (Microsoft’s assumption is that OCS is the master presence platform but many companies will have more than one presence aggregation point)?

To paraphrase Ronald Reagan’s challenge to Mikhail Gorbachev at the Brandenburg Gate: Open this gate! Unified communications providers, tear down this wall!

Carola Mamberto has an interesting article (subscription required) in today’s Wall Street Journal on the corporate adoption of instant messaging. Presence was highlighted in this article as a key differentiator of IM vs email, but the author put the word presence in quotation marks. When quotes are no longer used in such contexts, we’ll know presence is truly mainstream.

Yesterday at the Enterprise 2.0 conference, I participated in a panel discussion entitled “Presence 2.0“. Since the panel included some of the usual suspects from various past discussions, I decided to use the 2.0-ness of the title as an excuse to share some of the things we’ve been thinking about what presence might mean in the future. In particular, that we as an industry tend to make the problem too hard. Once users have several hundred people on their contact list, their desire for tweaky rules and individual configuration options starts to wane.

One way around this is a concept I’ve started calling “EigenPresence” (it’s important enough to me that I re-branded my blog to reflect the concept). The reputation for my digital identity is made up of multiple small pieces (on/offline, geographic location, mood, etc.), which can be combined into a single presence stream. If you were to integrate this stream over time, you would have the reputation associated with my identity. To answer Alec’s question, yes, I see Facebook, MySpace, Twitter, and the like as different bits that get integrated into this stream to build up my reputation.

I’ve posted my slide deck(5.6MB) from the panel, if you’d like to see them.

One of the coolest companies using the Jabber XCP platform is Me.dium, which is innovatively presence-enabling the Web. They recently announced raising $15 million in a second round of funding. I am still chuckling at how their CEO, Kimbal Musk blogged about this achievement.

Congratulations and thanks for injecting some humor into the world of presence!

Presence and real-time messaging are core themes of applications and services in unified communications and collaboration. In these user-centric worlds, applications, users, and devices must share presence, messages, and data. There is not (nor will there be) a single communications protocol that spans this diverse and growing universe of communications endpoints.

Based on the activity in our pipeline and the OEM deals we’ve signed (click for a recent example) Jabber is becoming the de facto standard for presence-enabling existing services and applications. Jabber easily bridges legacy and standard protocols to aggregate presence with speed, scale, and security. Jabber, Inc.’s technology is multi-protocol now, and it has the flexibility to extend to future protocols as they become established.

We were chatting the other day with an industry analyst and he started reeling off the “Web 2.0″-ish companies he’s working. We asked him about presence, and how these companies are going about making their services live.

The response was surprising and practically made us yell, Why in the world would they do that? You see, many of these companies view presence as core to their offering. Totally agree with them there.

As a core component many of these folks have gone about the business of trying to build their own presence server. The theory seems to be that “our application relies upon the ability of our users to know the presence of their buddies, and we therefore must own the presence engine.”

I beg to differ. Your service also needs a web server, and a bunch of hardware, and network connectivity, etc. Do you need to build all of those components yourself? I would argue that for many of these companies, presence is backend functionality, the application they build on top of it and how they market it should be their core focus.

At Jabber, Inc. we’ve already done the hard work with a massively scalable presence server that will interoperate with any network and just about any device. You can embed Jabber presence into just about any application and aggregate the presence from other devices and applications as well.

To illustrate the point, we recently closed a deal with a Web 2.0ish company which had been using an open source presence server (which is a nice way to get started.) But once they realized that their application and the success of their business was predicated on the ability to support millions of users, they had to go shopping and arrived at Jabber, Inc. because we’re the only store on Massively Scalable Avenue.

When Jabber, Inc.’s far-flung road warriors got caught by the recent snowstorms, presence was our first line of communication. Some stranded travelers wrote custom presence messages such as “stuck in Dallas, call my mobile”. Others used mobile IM to see who was available at headquarters to help them make new travel arrangements. In one case, colleagues on separate trips were able to meet up to share a rental car back home. With presence so ingrained into the Jabber, Inc. culture, no one was unaccounted for and people got help in real-time.

With the New Year, Jabber, Inc. enters its eighth year in the presence business, so it isn’t surprising that we use presence technology almost instinctively. What I find surprising is that there are so many organizations that are entirely presence-free. Sure, plenty of people are using enterprise and public IM to get their work done more efficiently, but typically, presence is only used to see if someone is available for a phone call or IM session. This situation is going to change radically in 2007.

I hereby go on the record boldly predicting that 2007 will be the Year of Presence in mainstream IT. Business decision-makers and IT professionals will realize that it is imperative to presence-enable communications and business processes, just as it was imperative to network-, then Web-enable business applications and processes in the 1990s. Be presence-enabled or be square. Don’t say I didn’t warn you.

The principal catalyst will likely be telephony, the technology invented 130 years ago, in the Centennial year of the United States. All forms of real-time communications benefit from presence and phone calls are the mainstream real-time communications medium. As digital telephony makes deeper inroads into the enterprise, presence will tag along and become integrated into the basic infrastructure of business.

While there will be growth in the business use of IM, that isn’t my point. The high-order bit is that from this point forward, real-time presence will be a basic information technology requirement. It all started with the dialtone. In the Web 1.0 era, Scott McNealy coined the term “big friggin’ WebTone switch” to capture the imperative of Web-enablement.

We are now entering the mainstream presence era, where aggregating and pervasively embedding presence becomes a business-critical IT mandate, just as becoming Web-enabled was back when Scott McNealy first spoke about Webtones. Jabber, Inc. has a programmable and scaleable real-time presence engine, which is an excellent foundation for the Big Friggin’ Presence Switch.

Best wishes for a happy, prosperous and presence-enabled New Year!

Goodness gracious, social networking is so in that it is a key element of Time’s Person of the Year!

Whenever something gets hot, there is bound to be backlash. Enter the concept of anti-social networking, which has been gaining momentum in the blogosphere following the explosion of social networking sites. This movement is the antithesis of social networking, as presented in anti-networking sites (some starting as sarcastic jibes) such as isolatr and snubster, where you can create a list of people to erase from your communications sphere of influence.

It may seem counterintuitive, but just as presence is key to effective social networking sites, presence is also critical for anti-social networking. You have to know the presence of specific people, places and things if you want to avoid undesirable situations. Or at least, you need to know they are not where you are. The announcement of a child-tracking service using GPS-enabled mobile phones has set off predictable teeth-gnashing about privacy concerns. I’m concerned about privacy, but this type of service doesn’t send me into Orwellian cold sweats. I have quite the opposite reaction. If the network knows where I am, it can help me avoid undesirable situations, such as crowds, traffic jams and yes, even people that I would just as soon avoid. If used creatively, presence technology can enhance privacy.

The anti-social pioneers tend to be a bit harsh, writing about things they despise, abhor, detest, etc. This extremism runs the risk of throwing a useful concept out with the hatemongering bathwater. Anti-social networking can be useful - even among friends! Most humans, at least occasionally, want to do things alone or with a very specific other person. Or, an activity that might be fun with a few people, becomes grueling when the crowds packs in. Presence information can help run the interference necessary to achieve these ends.

Social networks form communities of people with mutual interests. But what happens when mutual interests conflict? When you are after a resource in short supply, letting your friends know your plans could be counterproductive. The law of supply and demand can be cruel when supply is limited and something comes up to drive demand…such as a discussion within your social network. If I want a quiet vacation on a secluded beach is it wise to share my plans with all of my buddies? Are tickets tight for a game or concert? Then it’s probably not a good idea to chat about going until I’ve bought my own tickets.

Then there is the benefit of exploiting low-priced resources in good supply - getting a deal on things in times of abundance. I want my week at a secluded beach house, but at a low price. So I get a deal on the house because I am notified in real-time that someone just cancelled their reservation. That’s a presence change: From reserved, or not available, to available, by the way.

How about avoiding the crowds to have a better shopping, dining, entertainment, travel, etc. experience? Consider the class distinctions in air travel. First Class means more personal space, better food and less hassle…a better service experience, in other words. What if there were ways for companies to provide a superior service experience to their customers, just by letting them know when they can enjoy more privacy, quiet and elbow-room? Enterprises that figure this out are going to have some of the most loyal customers and profit handsomely from their efforts.

The concept of load balancing - allocating work to resources with spare capacity - has been around for a long time. From movie matinees to grid computing, profitable efficiencies are realized by utilizing otherwise slack resources. The quantitative gains have been studied and documented in operations research and systems management disciplines.

But the brave new opportunities are qualitative: The focus is on providing a better experience for humans, instead of machine utilization improvements or optimized process efficiency. This brings us back to the secluded beach vacation. The current model follows first class air travel - I want space, I pay for it. But the new presence-enabled model lets me find times and places where the beach is most likely to be all mine - without additional charge to me, but with incremental revenue to the owner of the house.

I hope I don’t see you there!