IBM vs Microsoft for Unified Communications

There has been a lot written in the past week about IBM’s announcements during VoiceCon and the additions IBM is putting into Sametime 8. Many of these are targeted actions to compete more effectively with Microsoft in the Unified Communications space. IBM’s recent announcements include support, via Siemens, to integrate with existing PBX systems, IBM’s acquisition of WebDialogs, and IBM’s expansion of SameTime to include Persistent Chat.

In a recent Information Week article, it is stated that IBM’s approach is different than Microsoft’s because IBM’s solution allows companies to leverage their existing PBX systems while Microsoft’s solution requires companies to rip and replace.

When reading the above article and press releases, a few things come to mind:

First, the Information Week article does not consider Microsoft’s VOIP as you are campaign, which is built around integrating with existing PBX systems. Whether or not you believe this is a Trojan horse strategy, Microsoft clearly has a short-term solution for integrating with existing PBX systems, whether they are from Cisco, Nortel, Avaya, etc. This is a good thing since Office Communications Server, while it can act as a standalone PBX, is not yet ready to handle very large organizations.

Second, the Information Week article points to the Microsoft vs. IBM battle for Unified Communications, and points out that IBM’s goal with Sametime 8 is to get out ahead of Microsoft (or stay ahead according to IBM’s Rhodin). One feature that is highlighted is the screen sharing capability that will be available in Sametime 8′s Advanced Version. This is mentioned as a way to get ahead of Microsoft despite Microsoft having application and screen sharing in its product (from the Placeware acquisition) for years (first in LCS 2005 and then again in OCS 2007).

All of these points however are not nearly as interesting as the lack of mention of Cisco. Cisco is investing heavily in the Unified Communications space and I have often wondered how the relationship between Cisco and IBM is faring given rumors that IBM wanted to buy Webex but that Cisco bought it out from underneath them.

Either way, it strikes me that the Unified Communications race is by no means a two horse race. Furthermore, as a veteran of producing Persistent Group Chat products for Unified Communications and Real-Time messaging solutions, I am excited to see Persistent Chat mentioned as one of the key components, along with voice and live meetings, in the race to win the Unified Communications desktop.

Live from Tech Ed

Day 4 of Tech Ed marks the end of the expo floor. We have been here all week demo’ing Persistent Chat (MindAlign) running on Microsoft Office Communications Server with integrated video. The turnout has been fantastic and needless to say, everyone has walked away with a lot of excitement about what we are doing in this space.

Some general notes that were especially interesting or exciting:

• Customers! The world understands Persistent Chat. That is obvious by the sheer number of people who came by our booth asking about it, speaking the language, and talking about real deployments. This was great to see.
• Chris Mayo stopped by to see our latest MindAlign 2007 product. Chris is now part of the Microsoft Unified Communications team as a Technical Evangelist. Back in the day Chris was with Microsoft in the Chicago area and helped us jump start our .NET initiatives. It was great to see Chris and show off our new stuff as MindAlign 2007 is now released after a long haul of development and converting from our previous development and deployment environment.
• Many other members of the Microsoft Unified Communications team stopped by to check out our latest software. It was fun again to show off our video integration into MindAlign. This integration was built with the latest Unified Communications Client APIs from Microsoft, and is part of the work we are doing to integrate telephony, voice, video, and conferencing through Microsoft Office Communications Server (OCS).
• Silverlight, WPF, new stuff, etc: there were some great demos and sessions about integrated search, SilverLight applications, etc.

Speaking of video integration, hats off to the MindAlign 2007 dev team and to Parlano IT . It was only about 1 ½ months ago when we decided to demo video integration at Tech Ed. I can’t say it went off without a hitch, but once we got it up and running it looked fantastic.

Now it’s off to Universal, or not, depending on the rain…

Blogs, Wikis, IM, Persistent Chat… How to make sense of all of these?

I was asked today how I would compare Wikis, Blogs, and Persistent Chat. Then, once that comparison was done, throw SharePoint into the mix. In the end, the ultimate question was, if someone has SharePoint, which in v2007 includes Wikis and Blogs, then why would they need Persistent Chat?

My first answer to the question was simple: conversations in the workplace exist with the purpose of achieving an outcome. The outcome is typically an artifact of some kind, where the artifact can be a document, a proposal, a set of milestones, an action plan, etc. In historical terms, these conversations always took place in person or on the phone. With the addition of Unified Communications solutions, we are now able to add video, video conferencing, live meetings, etc. to the mix of conversations. But in the end, the goals don’t change: someone needs to get something done and therefore they need to converse in order to achieve this goal. So, the conversation is something real-time, like IM or Persistent Chat, whereas the artifact is something that is published, like a Blog or Wiki entry.

Simply put, there is conversational of collaboration and there is document-based collaboration. Conversational collaboration comes in the form of person-to-person conversations, voice (telephony, VOIP), and video conversations, in addition to text-based conversations in the form of email, IM, and Persistent Chat. Document-based collaboration includes Blogs, Wikis, Intranets, and Document Management systems. Conversational collaboration is useful for arriving at ideas and conclusions. Document based collaboration is useful for documenting those ideas and conclusions.

Another way to classify these collaboration tools is to consider the following graph:

On one axis (Y) collaboration tools can be classified by how dynamic they are. On the other axis (X) they can be classified by the level of persistence within the solution. Below is how I would classify these collaboration solutions:

Person-to-person, voice, and video are all the most dynamic forms of collaboration, but they inherently have no persistence as there is typically no record of the conversation. IM is slightly less dynamic since people generally type slower than they talk, however IM conversations are usually not persistent.

Intranets are extremely persistent but most of their content is very static and does not frequently change. I have argued in previous blog posts that the static nature of Intranets is one of the primary reasons why the Intranet model is generally being phased out in favor of other more dynamic forms of collaboration.

Documents are more persistent since you can PDF a document and keep the contents forever. However they are also slightly more collaborative as you can exchange documents and mark edits, comments, etc. within those documents. Anyone who has been involved in a contracting process with lawyers knows what this process looks like (it is painful).

Wikis and Blogs are tough to classify in comparison to each other. However I think it is easy to say that Wikis and Blogs are more dynamic than documents even though they may or may not be as persistent as documents. On one hand Blogs are very persistent because people typically do not modify their posts after the fact. On the other hand they are not very persistent because Blog entries are typically not organized by anything other than author and old entries scroll off the page and are lost in time. Blogs are collaborative only because people can comment on posts. But this concept of commenting on posts is nowhere near as real-time and dynamic as IM, Persistent Chat, or Voice/Video. In some regard Blogs can be compared to Email since an inbox is usually one un-organized stream of incoming emails. Blogs are typically one un-organized stream-of-conscience from a particular person.

Wikis on the other hand are very dynamic since many people can change the text of an article. But in the end Wikis are typically just a shared document, where the documents are organized around topics. Someone can publish information on a topic and others can edit that content. Wikipedia is the best example of this. It is an encyclopedia that everyone edits and therefore arguably has the best content. While this is a great place to document ideas, it is not a very fluent and dynamic way to have a conversation.

Persistent Chat is as dynamic as IM since you communicate in the same was as you do in IM. Arguably it may be slightly more dynamic since it is easier to share files in Persistent Chat rooms than it is in IM (many IM solutions do not support file transfer). But Persistent Chat combines the real-time nature of IM, persistent nature of Blogs, and the topic-based nature of Wikis. So you can go to a room/channel that is based on a topic, search through archives of what was said on that topic, and then participate in the conversation of that topic in real-time. If the team in the room/channel comes to a conclusion and/or artifact, that artifact can be published to a nWiki or Blog. But in many cases it is as important to understand how you came to the decision as it is to knowing what the decision was.

Ultimately, someone might ask: If I have Blogs, Wikis, and IM, why do I need Persistent Chat? My answer would be that after reading this article the only way to have a conversation with me about it is to post a comment. Yet that is only useful for a small number of comments. An IM conversation would be better, but what if we wanted to add a 3^rd party to that conversation? And what if that 3^rd party wanted to be able to search through everything that was said before they joined the conversation? That is a concept that is only available through Persistent Chat.

Dated and Confused

I read a great article in the Wall Street Journal today written by Andrew Blackman about Intranets. The title of the article was “Dated and Confused” which in my opinion is a perfect description of the corporate intranet.

The article discusses several points about corporate intranets and then notes how wikis and blogs are being used solve traditional intranet problems. For smaller startup-up companies like Parlano, where I work, wikis and intranets are the same thing. We use our internal wiki as well as Sharepoint to store documentation and information for our company. Having used an internal wiki for several years I can say that the problems of intranets have only partially been solved by wikis.

The problem areas can be divided into a few categories.

Input

First is the problem of input, or getting the information into the intranet. Several people in the WSJ article were quoted as saying that the information they needed simply was not available on their intranet because the people who had that information did not post it; instead the information was “in someone’s head, or on a drive somewhere I didn’t have access to”. Everyone who has experience using any type of corporate intranet or blog has had the same experience. You have information to share, but you are either not sure where to put it or you don’t know how to format it properly. You try to figure it out but then you run out of time and the thought or information is forever stuck in the depths of your mind.

We use two wikis – one is a basic open-source wiki and another is twiki. Both make it much easier to publish information although you are still required to learn the formatting tricks. In our first wiki it was nearly impossible to upload a file. You could do it, however it required uploading the file to a share and then manually formatting the url so people could link to the file. You want document versioning with that? Forget it. The second version allows for file versioning and is somewhat similar to our SharePoint implementation. So there are improvements. But still, what if you don’t know where to put the information?

Output

The second major problem is getting the information out of the intranet in order to use it. While the age-old problem is organization and finding the information you want (one company in the article recently had 212,000 pages on their intranet!), this is lately being solved by sophisticated search. The problem of the intranet is the same one I have on my hard drive: I can’t remember where I put stuff and therefore I need a good desktop search. If you have a good search on your intranet or wiki then organization should not be your problem.

However, I still find it difficult to get files from an intranet site, a good wiki, or even SharePoint. Part of this comes from me being a software developer by trade and being used to a good source code repository. The other part comes from me now being in management and needing to access information from my laptop while on a plane. With a good source code tool you can, with one click of a button, synchronize all of your data and download anything that is out-of-date to your pc. That way when you are disconnected you can still access everything. When you reconnect your changes are automatically sync’ed into the repository. It drives me crazy that our intranet solutions don’t do this and therefore I have to manually check timestamps of documents when I can’t remember whether I edited it since it was checked out. Hopefully SharePoint 2007 has solved this problem and I just don’t know it yet. Or maybe I have to wait for further Groove integration.

The Rub

With all of that said, the real problem is the concept of dynamic vs. static information on an intranet site. The WSJ article addresses this and refers to Social Networking aspects of Microsoft’s and IBM’s latest products. I particularly like the “social distance” concept in SharePoint 2007, where searches return not only documents, but also people knowledgeable in the search, where the people are listed in order of how well you know them.

In the end, however, an intranet site is created to address a topic. And as David Gootzit from Gartner said, “The value of any network is dependent on participation, on the numbers involved”. But if the site is related to a topic, then where is the topic-based conversation in the search results? And, if the success of the site is dependent on the participation, where is the metaphor for facilitating real-time collaboration around that topic (rather than amongst individuals)?

We have often discussed how Persistent Chat, which is a real-time, topic-based conversation between people, can turn the model of an intranet upside down. It can do so by creating a dynamic, real-time communication environment where people always start their days in order to communicate with others around their topics of interest. Yet the conversations in these “channels”, or rooms, ultimately lead to exchanges of documents, tasks that need to be assigned, or artifacts that need to be logged. While much of the discussion around this, and even the decisions, can be found in the “backchat”, or history of the chat conversations, a Wiki page or intranet site dedicated to that topic is the perfect complement to such a conversation.

Intranets have been around for years and companies have spent millions, if not billions of dollars funding designs and redesigns of their corporate intranets. While it still remains to be seen, I am willing to be that none of these redesigns will work until real-time communications, such as Persistent Chat, are added into these historically static collaboration environments.

Better Customer Service through Collaboration

I had the pleasure to meet with a customer this week whose primary objective over the next year is to increase their ability to serve their customers. In this customer’s market, services are quickly becoming commoditized and margins are being squeezed. Therefore, the only way to maintain their margins and their premium relationships with their customers is to integrate themselves more fully with the customer’s business and build a world class organization of coordinated people to service the customer.

I am sure that this customer’s problem is not unique. The same statement, about commoditization of products and squeezed margins, could probably be said about several industries. But the answer, or at least this solution (there may be many approaches) seems to be consistent. Knowing your customer is always going to help you build better products for that customer. And providing a more cohesive and coordinated front to that customer will always lead to them wanting to utilize more services from your business.

Due to the last decade of M & A activity, many organizations have become large in order to offer a vast, diversified set of products to customers. But many of these organizations are quickly feeling the pains of the customer I mentioned above. This pain is that there is always a relationship or account manager that will interact regularly with the customer. However at some point the account manager will need to delegate customer requests to people within the organization who provide the products. Yet in many organizations these various product teams were built inorganically, and therefore they are not sitting right next to each other. The result is a lack of coordination on the customer’s behalf across product lines. Furthermore, it is nearly impossible for the account manager to constantly stay on top of requests for the customer.

In this particular use case, our customer will solve this problem through better collaboration. The idea is that more people within the organization should know intimate details about the customer, and that each product team should coordinate their efforts in order to better service the customer. For some, collaboration comes in many forms. For example, collaboration may utilize portals and indexed data. But the key problem with using these solutions alone is that data must first be created in a place where it can be indexed. This requires people to end their conference calls and/or meetings and then write up notes or action items for other people to see. In many cases this does not happen.

This is where we have seen Persistent Group Chat make a huge difference. While Persistent Chat is not a workflow tool for managing discrete actions, it is the perfect solution for capturing the dialog between teams. The reason it works so well is that the teams communicate within the same tool that is also logging the content and information. As a result, there is no need to retrospectively write meeting notes or action items. The conversation is instantly logged and others on the team can read the archives at any time (assuming they have the correct permissions).

In the use case of the account manager, they can share persistent chat rooms with the product teams and discuss requests specific to the customer. In the communication with the customer, the account manager will have better knowledge and provide better answers. In cases where the customer needs to interact with a team, this interaction can also take place in Persistent Chat rooms (we call them channels). Not only will the customer have the impression that they are being serviced by an army of people, but the dialog will be automatically persisted so that both sides of the conversation can read through archives when necessary.

This is the type of simple solution that can be employed to improve customer service and ultimately allow companies to maintain their competitive edge and margins.

The Obsession with Google

I recently read a blog post by a friend of mine, Graham Lawlor, who admitted that he’s a bit obsessed with Google. In his posting Graham references Google’s “game changing” technologies such as search and web mail. Then he discusses how IM/Chat needs a game-changing application and that Google would be a prime player for such a change.

While Graham made some good points, as did the Forbes article that he referenced, I don’t get the obsession with Google from within the tech community in the enterprise. Sure, Google changed, or actually defined the search landscape. And yes, it’s obvious that they made a mint on the advertising model built around search. But how does this apply to the enterprise other than making lots of money from enterprises trying to advertise their brands on search results? I wouldn’t be the first person to state that Google does or does not have a place in the enterprise. But I have to wonder, if it did have a place, what would that place be?

In trying to define that answer I tried to put aside my general feelings that Google is over-hyped. But I’m not sure I got too far on that. Here’s why:

First, Google has some great products and they obviously have smart engineers. And they have a great brand, which will go a long way especially when trying to sell advertising space on the Internet. But I am having problems bridging the gap between advertising revenue and enterprise software revenue. A lot of people have been discussing how Web 2.0 and Enterprise 2.0 will change the enterprise software landscape. This will be done by forcing application vendors to design new delivery models for their software applications, and make it easier for people to access their applications in more easily purchased and deployed formats. But does this mean that software will be free for enterprises because it will completely funded by an advertising model? I really hope not because as an end-user I would not be happy in that model. Maybe I am wrong and Google has some other strategy. The certainly wouldn’t be the first ones to try it (witness Yahoo’s not-so-recent move and AOL’s recent move to create enterprise offerings).

Next, is the enterprise ready to move their data outside of their organization? While Graham comments that Google changed the game in webmail, webmail in fact has been around for a long time. While Google’s interface is nice (although I actually like Yahoo’s webmail interface better) and changes the paradigm for organizing email (because rather than filing them you simply search for them), I don’t think that Gmail a) changes the game or b) that this will have a major impact on large enterprise software implementations. We simply haven’t seen large organizations move their entire enterprise messaging applications external to their organizations, unless it is a managed environment rather than an open, hosted community. Do you think a major Investment Bank will move their email infrastructure into Google webmail? I am guessing no. The reason is that there are too many data points that require integration with the messaging infrastructure. For example, we have just spent years upgrading all of our products to integrate tightly with a corporate directory so that a user can be identified once for every application, including vertical line-of-business applications, within an organization. Now we are starting to see demands for integrating with the phone system, desktop video, video conferencing, and other items that require advanced levels of enterprise infrastructure. How would a Google messaging infrastructure integrate with a company’s phone switch?

In my opinion, Google will surely have an impact on the enterprise. However, their impact may in some cases be indirect. Instead of directly changing the game by causing millions of messaging (whether it is email or IM/Chat) users to migrate to a Google model, I think Google will influence enterprise applications to upgrade their thinking and delivery of their applications. For example, we see that Microsoft Office 2007 has already integrated the concept of search throughout your entire mailbox, much in the same way that Google introduced this search in Gmail.

I also think that Google, and other managed/hosted infrastructures, will have an impact on small to medium size businesses that do not have large/existing messaging and directory infrastructures. These organizations will require a place to go to get their identity, and they will require a way they can login and communicate with others. However, I am not convinced that Google will be the one to solve this problem widely as I can’t see a financial trader patiently watching advertisements flash on the side of their screen while they are trying to communicate price information to a potential customer. Instead, that trader will require an application that completely optimizes screen real-estate, one that meets all of their very specific compliance requirements and one that delivers messages faster than the messaging applications of their customers. Is this Google? We’ll see…

More on SOA and Enterprise 2.0

Joe McKendrik posted today about how SOA and Web 2.0 will Stir Disruption. In the article, Joe referenced my previous post, and mentioned that this post focuses too much on the “technical weeds”.

This concept of technical weeds is exactly the point I am trying to make about comparing SOA to Enterprise 2.0. My point is that SOA is a technology; it is a way to build and deliver applications. Enterprise 2.0, however, is so much more than that because it represents a completely new way for people to communicate and interact. So, while I am excited about using concepts of SOA to deliver applications, I think that tightly coupling the success (and hype) of SOA to Enterprise 2.0 actually belittles the promise of Enterprise 2.0.

One piece of data that represents the foundation of my beliefs that SOA is possibly being over-hyped are the statistics of SOA based APIs and “Mashups” from the Programmable Web. From Dion Hinchcliffe’s post, The growth of mashups continued throughout 2006, as of December 13, 2006 there were 348 APIs registered and 1350 mashups. While these numbers are more impressive than say 0, they are nothing compared with the number of website that were created in the previous revolution which was the World Wide Web. So while I am sure we will continue to see a rise in SOA based applications, I am hopeful that Enterprise 2.0 will be much broader and grander than SOA will ever be.

Web 2.0 and SOA: Are they related?

I read a blog entry today that stated that Service Oriented Architecture (SOA) and Web 2.0 are Disruptive Innovations. The writer referenced various benefits of SOA, such as Situational Software, RSS, and Mashups; several terms that many people have never heard of before. Situational Software was defined as “Rapid Software Development” by non-programmers to solve particular business problems on-the-fly using components that exist somewhere on the Internet. Mashups refer to applications built using open APIs available on the internet. RSS, which most people know, was also referenced as a way to syndicate content and easily include this content in other applications. The post referenced Web 2.0 applications such as Linked In, Wikipedia, Google’s “Office 2.0″, and others.

Then, the writer referred to Clay Christensen’s definition of Disruptive Innovation and stated that Web 2.0 and SOA are Disruptive Innovations based on Christensen’s definition.

While I thought the post was interesting, it fell victim to what I think is over-heated hype about Web 2.0 and SOA. Granted, Web 2.0 will change the way we work, interact, and purchase software. We already see this today in applications such as Linked In and Wikipedia. Because of these applications and things like Office 2.0, sure, maybe you could classify Web 2.0 as a disruptive innovation. But what I am missing is the connection between SOA and Web 2.0 and how SOA also, by default, ends up in the disruptive category. I mean, can we really compare SOA’s impact with the introduction of the telephone (one of Christensen’s examples of a disruptive innovation)?

Specifically, here is my problem with this over-hype: Web 2.0 is great. SOA is great. Nobody will deny that. In fact, as a CTO I try to employ as many of these concepts as possible. I write about Social Networking (arguably a Web 2.0 application) and we attempt to integrate these concepts with our products. When we design new products, we attempt to build them using a Service-Oriented Architecture. But is SOA disruptive? To me SOA is an evolution of concepts that have been around for decades. Software developers have long been figuring out ways to componentize what they build so that they can utilize these components in different ways. The fact that we now access these components through HTTP and Web Services is great, and makes programming much easier and more extensible. But is this disruptive over something like the CORBA or RMI or HTTP programs we wrote years ago? Back then we could write distributed components that programs from multiple languages could access, and these services could be published into directories. Now we have programs based on Web Services, and these programs can be published using Web Services Description Languages (WSDL) in various services directories. And we have applications that allow semi-fluent technologists to easily incorporate logic from these services into programs. But is this disruptive? Does this change markets or create new ones? I don’t think so. At least not yet.

There is a stronger argument in classifying Web 2.0 as disruptive, but I fail to see the tight connection between SOA and Web 2.0. Sure, it is possible that Linked-In is built on a Service-Oriented Architecture. But it might not be. For all we know it might be a simple CGI application that is monolithic and has all of its logic written in one place. And what about Wikipedia or any of the new Office 2.0 applications that you can run from companies such as Google? Are these built using SOA? Again, maybe they are, maybe they are not. But does it matter? End-users don’t care. My point here is that there is not a direct relationship between Web 2.0 and SOA. The only reason Web 2.0 can be considered disruptive in my opinion is because of the functionality it deploys to the end user, but not necessarily because of the building blocks on which it is built. With that said, in my opinion AJAX has a much bigger impact on Web 2.0′s success than SOA, since AJAX allows desktop-like functionality from within a browser application. Once this becomes richer, then maybe Web 2.0 will be truly disruptive.

Finally, what does the development process have to do with this? The writer referenced the way that applications are built, and that longer, planned out software development cycles are a thing of the past. I don’t buy it. First of all, software developers have been using iterative and agile development processes for years. Extreme Programming has been around long before SOA and Web 2.0 were invented and hyped. One of the major premises of these development methodologies is that it is more beneficial and productive to release software early and often in order to get feedback from users. We have been using agile methods in our company for years, and it works. The fact that Google releases software in this way does not make it more or less disruptive in my opinion. Nor is it something that is unique to Web 2.0.

To be sure, we will all benefit from Web 2.0 and SOA. Maybe I am just cynical because I have lived through a couple cycles of hype. But at this point I think Web 2.0 and SOA are simply new ways to think of and do things, but not yet earth shattering. Web 2.0 might be edging close to this category, but SOA is not there yet.

What is Synchronous?

Last week a customer asked me whether I would classify Persistent Chat as synchronous or asynchronous. Good question. My simple answer is both. In fact, chat is the perfect application to bridge the gap between the synchronous and synchronous world. It is synchronous, or real-time, when all members of a team are available and actively participating in a conversation. This is great when your team members are in overlapping time zones but maybe they are unable to sit next to each other due to their physical locations. At the same time, Persistent Chat can be asynchronous since a user can join a conversation after the fact and read through the conversation history, or backchat. This is useful when you are working with a team that is in a different time zone, such as an offshore development team. Or perhaps you are traveling and you simply want to read about what your team did while you were away from the office.

Because of these scenarios, the answer seems fairly complete: Persistent Chat is both synchronous and asynchronous. But consider this: what if Persistent Group Chat actually changes the definition of what is synchronous? Maybe synchronous no longer means a group of people communicating in real time, but instead refers to a group of people being completely in-sync on a topic of conversation. Persistent Chat does this through the persistence of the conversations as well as the filters and intelligent notifications that ensure that people are always up-to-date on information that is important to them. The result is that they are in-sync with their team members, regardless of whether the team is able to communicate in real-time.

In the end, Persistent Chat is the solution that brings teams together around topics, and keeps everyone up-to-date on those topics. Persistent Chat keeps everyone in sync, and therefore Persistent Chat should be considered Synchronous.

Like Wikis for the Enterprise, But Better

Yesterday I was asked how Persistent Group Messaging relates to Enterprise 2.0 and Web 2.0. My answer was that there are similarities and differences. But after reading the Wikipedia definitions (Web 2.0 and Enterprise 2.0), I think the similarities outweigh the differences.

Think about it: Web 2.0 is about communication that emphasizes collaboration and sharing with others. Enterprise 2.0 involves the same concepts but applies them to the enterprise. Enterprise 2.0 is major advancement over Enterprise 1.0 solutions such as Intranets. For example, Intranets require structure before collaboration, which in many cases lead to inappropriate structure and low adoption rates. In Enterprise 2.0, collaboration comes first and structure derives from that. This typically leads to tremendous adoption rates for Wikis and Blogs, both which fit within this category. Group Chat is very similar because it enables people to collaborate in teams around topics. While most successful chat communities ultimately end up with structure based around workflows, that structure is usually derived by the community rather than explicitly stated up front. Regardless, the most important aspect is that Group Chat requires no training and the community is very fluid and dynamic, just like the way people interact in social situations.

This relationship between Persistent Group Messaging and Web/Enterprise 2.0 was emphasized for me today while reading an article by Melanie Turek titled Alternative to Wikis & Blogs for the Enterprise. The article highlights the strengths of Persistent Group Messaging, or Group Chat, and discusses its usefulness in the enterprise. In thinking about the relationship to Enterprise 2.0, it is also possible to relate Persistent Group Messaging to social networking. In chat, it is easy to find topics that are interesting and therefore extend your network based on who you interact with in Persistent Chat rooms. Yet this is different than most social network solutions because it is based on “communities of interest”, or chat rooms, rather than n-degrees of separation as is prevalent in most other social networking sites. We always say that in a large organization it is easier to understand “what” you need to know rather than “who” you need to talk to in order to get information. In other words, someone you don’t know on the other side of the world may have an answer to your question. Aside from significant help, you may never find that person or that answer. Yet you can easily find a chat room where the topic is discussed, and from there the people in the room will lead you to your answer.

Melanie’s closing statement sums it up. When discussing Group Chat, she says “For the enterprise, it’s like a wiki, only better”.