So

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".

Group Chat Grows Up

David Strom posted an interesting article last week about Group Chat going main stream. It's great to see people writing about what we have been seeing in the industry for years. Of course, our customers have been using Group Chat, or Persistent Group Messaging, for years. And while we like to think our customers are smarter than their competition, they are not by any means early adopters.

However, David makes a good point that while Group Chat has previously been used for mission critical operations such as defense and financial trading, it is now used and useful practically anywhere in the organization. In fact, on page 3 of the article David states that Chat is as easy to support as email and other messaging systems. In practice, we have found that Chat is not only as easy to support as these other systems, but chat is used to support these other systems. How? Because Group Chat is the way that IT teams coordinate system upgrades, outages, and other events which were previously very difficult to do over email and/or very large conference calls.

The Evolution of Mail

Nick Fera published an interesting article yesterday about the evolution of email. Is email dead? Of course not. Would I like it to be dead? I’m not sure. But I do know that I would rather communicate using other tools under the Unified Communications umbrella, such as IM and Persistent Group Messaging.

We have had conversations with partners and colleagues in the past about email vs. IM. In fact I posted recently about Group IM, Group Chat, or Email, where I discussed the differences between IM and Email from the perspective of persistence. Based on trends of IM adoption plus increasing trends of text messaging among Generation Y, it seems like the general population is gravitating towards a more instant form of communication rather than one that is not so instant, like email. But when discussing whether IM will replace email in the enterprise, the conversation always comes back to the concepts of group communications and persistence. Without persistence, IM cannot replace email. Without group communications, the same is true. However, a form of communication that involves both group communications and persistence plus the immediacy of IM is something that has a chance of offsetting the massive footprint that email has today.

However, Nick’s article was interesting because it points out that we may not necessarily see a replacement of email as much as an evolution. Through new modes of communication, such as IM, Persistent Group Messaging, and other aspects of Unified Communications, we might instead see email evolve to serve a slightly different purpose. When that happens, the IM-like email conversations that we have today on our Blackberry’s will happen where they belong: in IM. The group communications will also happen where they belong: in PGM. What may be left might for email will be a different method of distribution of content that email serves quite well. I look forward to this evolution.

The Impact of a Network Outage

It is a bit embarrassing that it has been so long since I last posted to this blog. But I guess it is a good sign that we are very busy around here…

Today we had a switch that sits between our office and our MindAlign (Group Chat) servers die, and so our teams (Dev, Support, QA) were without MindAlign for an entire morning.

When I arrived at the office, my original thought was that great, I can have some un-interrupted time to get some work done while the network is being fixed. What I realized is that not having a chat system is quite the opposite; I ended up being more un-productive as a result of not being able to quickly find information or drop ideas and tasks to other team members in chat.

I once heard someone say that if you have trouble falling asleep after waking up in the middle of the night with ideas and thoughts that you would counter this by keeping pen and paper on the bedside table. The idea is that you can write down the idea and that your brain would give it up, knowing that it was logged, and allow you to go back to sleep.

Ironically, today I felt the same way about not having chat. While working on a document for a customer there were several thoughts that came to my mind. However, instead of being able to drop a message into a chat room covering the topic of my thought, I was forced to either keep thinking about the concept and/or walk over to someone and talk to them about the topic. The result was that I was interrupted from my document, and therefore it took me longer to write the doc. Furthermore, there were cases where I needed information from people to complete the doc. Again, instead of being able to asynchronously drop a question, knowing that the answer would come later, I had to synchronously walk over to someone’s desk and ask the question. The result again was that I was less productive than I could have been.

We talk extensively about the way people work in an environment where everyone is connected to their peers in real-time. Sometimes it is easy to dream about the past and think about a time when we used to have less connectivity. Today taught me that while it may be quieter when you are not connected, quieter actually does not equate to being more productive. In fact I think that the opposite is true.

Effective Business Communications in Geographically Dispersed Teams

I read a great article today (Psychology of Effective Business Communications) that was written by Pearn Kandola and commissioned by Cisco Systems. Pearn Kandola are occupational psychologists who spend some of their time studying how teams of people work together.

The article is based on a report that states that globalization, atomization, and knowledge management “will have a significant impact on the structure, functioning, and distribution of teams within and across business”. Key to this is that while people will become increasingly spread out in order to service their markets, these same people will need to be more closely linked to the knowledge assets within their organizations.

The article then goes on to talk about how communications works in dispersed, multi-cultural, and virtual teams.

While there are some elements of this article that hit home and are right on the mark, I think some other pieces are missing. Specifically, the article makes no mention of one of the most significant communications tools for multi-cultural, virtual, and dispersed teams. That is Persistent Group Messaging, or topic-based, persistent group chat. Why do I think this is an effective medium of communications for these types of teams? Because for years we have been watching our customers manage such teams through the use of our tools. It doesn’t get any more dispersed and multi-cultural when you have one person sitting in London, one person in Singapore, and then a handful of people sitting under galvanized steel roofs in Africa while still more are sitting in ultra secure locations (leave your machine guns at the door) on trading floors in Columbia. Yet while all of these people are in different time zones and sit in different locations, they share research and trading information over MindAlign as if they were shouting across the room of a physical trading floor. This concept has revolutionized business where remote areas used to be starved from the rich and constant sources of information that are generated back at hub locations.

What makes this possible? This is where I think the article is right on the spot. The first key point is that teams of people must have trust in order to communicate effectively. But this is a bit of a catch 22 since communication is necessary in order to establish trust. The article points out that companies must facilitate development of effective trust using socialization strategies such as virtual coffee breaks and online chat rooms. Furthermore, the article states that trust building in virtual locations is difficult when people cannot observe the amount of effort or overhear what team members say when they are interacting with others. We have seen online virtual coffee breaks, or other discussions work. But more importantly is the concept of knowing what the other party is doing, and being able to get immediate feedback and validation from others about ideas. Think about being able to chat in real time with a team where half the people are chatting in their second language yet it is possible to have a complete and seamless dialog about ideas.

The next key point is about conflict. I especially like the comments that “spontaneous and clear communications is key to reducing conflict in all teams. This is especially important in virtual teams where there may be more ambiguity about what colleagues are doing”. Once again, we have seen this work for years using Persistent Group Messaging. In fact, we can relate this back to personal experience. Our company is itself geographically dispersed. We have core operations in Chicago yet we have sales, support, and implementation teams in London, Washington DC, New York, and Denver. Furthermore, there was a time at the beginning of our company’s history when we had development teams working out of their homes while we moved offices. During that time we were able to deliver 3 releases of software on-time with no loss of productivity. How? Because we were able to communicate effectively, monitor what each other was doing, and easily resolve conflict through constant and persistent communications.

Bringing it all together: Unified Communications

The article points out that there are multiple means of communicating, and each has its purpose. It then points out that the core attributes of communication: immediacy, symbol variety (availability of multiple cues in the medium), parallelism (can you communicate in multiple topics simultaneously), rehearsability (can you pre-edit what you write or say), and reprocessabliity (can you go back in and view archives) are seen in different communications tools. For example, video conferencing has high symbol variety yet has small rehearsability and reprocessability. Then it mentions Unified Communications. I think my definition of Unified Communications is slightly different than that discussed in the article. To me, Unified Communications means bringing together all of the said communications tools, including conferencing, voice, video, and Persistent Group Messaging. However, from my point of view there is one item that is the framework, or launch pad, for all other types of Unified Communications. And that is Persistent Group Messaging. Once again, I am stating this based on observing our customers, who stop using email in favor of PGM. Additionally, PGM is the first thing they start in the morning and the last thing they turn off at night. Once people are organized in persistent topics, then it becomes extremely easy to launch into voice conferences using a presence enabled contact list of the users within the topic or room. The same goes for data conferencing (Live Meetings, Meeting Place, etc.). So, from my perspective, virtual teams need it all. But the place to start is the easiest thing to deploy and the easiest thing to understand. And that is Persistent Group Messaging.

Mobile 911 in Chicago

Today Chicago executed what is being called the largest disaster/evacuation simulation ever run in the United States. One of the city's weapons used in the exercise was the new multi-million dollar mobile 911 center. This vehicle is highly impressive, with 115 telephone lines and connections into thousands of cameras around the city.

Reading about it reminds me of Jack Bauer on 24. It also reminds me of a recent entry I wrote about the 2006 Intergraph Conference, where I got a chance to speak about the role of Persistent Group Messaging in disaster recovery situations. The core concepts covered in the above entry are related to coordinating teams of people, some on-site and some remote, and some entering the conversation after others but still needing the full context of the situation. But there are a couple other things I have heard recently about disaster scenarios that are somewhat alarming. They are:

1. Keeping track of people: I have read reviews of recent disaster responses where one of the biggest challenges was communicating between agencies and keeping track of where assets and people are deployed. This is something that can be done at large scale with the use of secure chat rooms integrated with geospatial and map data.
2. Limitations of voice: A colleague told me a story about visiting the DHS after the Katrina disaster. The story was about walking into a command center and seeing lots and lots of phones, all w/ people talking on the other end, all sitting on the desk being un-heard because it is impossible for a human to pay attention to that many voices at one time. Again, this is an area where text-based persistent messaging can help, because with the help of alerts and intelligent consumption features it is possible to participate in hundreds of conversations simultaneously.

Some day, hopefully we will see some of these relatively cheap technologies deployed in the mobile 911 units and disaster response command centers.