The 1.1 in “enterprise 1.1″ is actually quite important. It’s not just an artifact of communication. I use it to reflect a very simple fact, it goes like this:

• First came Enterprise 1.0 – You know what it was about: control, secrecy (even amongst peers), need-to-know-basis, access-control, “business rules”, “process”, all that junk that business leaders learnt at all those very prestigious institutions where “business is war”, there is a thing called “guerrilla marketing”, social solidarity is abbreviated as “socialism”, where even selling you unneeded junk is called “market penetration” (guess why? ). Want to know what it feels like in Enterprise 1.0? Perhaps you do… Hypothetically, let’s say you worked at Ford Motors about ten years ago, when the Explorer was about to be released to great forecasts. While the car is being designed, a quick calculation in your Cad/Cam system shows that the vehicle will flip over under lateral pressures on its tires (e.g., turning a curve while breaking slightly). now, let’s say that, hypothetically always, you go to your boss with your findings. Here comes the test: what do you get?
  • If the answer is something like “A reprimand, severe admonitions, threats to shut the hell up… followed by a surprise promotion to a position far away organizationally from your last one, for which you need to sign a non-disclosure about your previous job that basically hands over your gonads and children to the company if you ever mention the incident again”, you already know what Enterprise 1.0 feels like. E1.0 is another term for “glacial, absolute and indisputable lack of movement and change”; what is, will be.
• Then, of course, Enterprise 1.1 showed up – What was it? Same crap, just marketing angles on top. A great example: SAS, cloud-based software, you may be old enough to even remember ASP. Whatever the case, this is the same old: same old control, same old secrecy, same old ideology, same old… but now you don’t even need to own the hardware. Why do I choose SAS, instead of many other categories? Well, because I consider SalesForce.com a perfect example of 1.1: “Change something that makes exercising control cheaper and you will create the illusion of movement”. What the software does is exactly what it did before; it’s just slightly cheaper (arguably) to operate. Slight of hand. E 1.1
• Enterprise 2.0 is now emergent – The pervasive Internet has made it possible for all of us to be heard (take this obscure blog as an example), but also to excite our network (something E1.0 and E1.1 would never let you do) around us, and in the process create conditions for many emergent phenomena: the same way that you can easily bring a freeway to its knees by synchronizing traffic across three lanes (usually right in front of me), you can now create a PR disaster for Ford (always hypothetically, of course), for killing hundreds of people in Explorers that turn over, over, and over, as soon as people turn corners and touch the brakes. Yes, you are that empowered, you just need to learn other rules of engagement (social networking 1.0.1), but you can do it, and Ford would have a very hard time sweeping you under the rug. You see, even as all those large companies have all this control-driven infrastructure, you, and your network, are not part of it: they can control their infrastructure, but it’s becoming too hard to control you: too many possible outlets for your voice… at least until this oxymoron called “social CRM” gets to “embrace you, the customer”. But that is another story, let’s go back to Reason #2.

The center of reason #2 is that E1.0, as well as E1.1, are paradigms driven by control, secrecy and exclusion; you “don’t need to know that the damn cars will turn over, that’s ‘proprietary’ information”, “you don’t need to know that your Internet 6 browser is exposing everything you do in the Internet to others –for the same reason”– and so on. We even have software and infrastructure to make sure  you don’t know. We call those pieces of software Content Management, Intranets, ERP, Back Office Apps, and oh, yes, CRM.

You see, CRM doesn’t let YOU the customer, see what the sales person knows about product defects. Nope. Neither does it empower to talk to many other customers on your terms, controlling the conversation yourself. What it does, is to make sure that the vendor controls the conversation, that no “proprietary information” is exchanged, that “business rules” are enforced. It’s role is to preserve the status quo, not to impact it. What is, will be.

Social business services, on the other hand, are all about you controlling conversation, relationships and interactions. It works because it lets you choose how to deposit your trust into individuals and companies, and it does so precisely by letting you control the terms of the conversation. As a result, “customer-managed relationships (CMR)” emerges. CMR is social, by definition and by its own merits; CRM, on the other hand, is the negation of social: it’s the total loss of control of the conversation by the customer.

So, why do these companies (mostly SalesForce.com) and pundits (too many to list) create the oxymoron?

• Good intentions by some pundits – If you believe customers should be empowered, or if you believe that they will be empowered regardless of what you say, “social CRM” is a good way to bring out the good in every one. That is cool, but it’s a contortion of an argument:
  • “Customers are increasingly empowered, they have too many channels, the channels are auto-emergent, and thus customers will take control of the conversation”. OK, I agree with that.
  • “Companies will need to adapt in order to sell to the new customer”. OK, I agree with that as well. As a matter of fact, when you look at the way the really big companies are selling these days, how they are creating “influencers” out of “soccer moms”, how there is a networked way of doing everything, even buying Clorox, how you can fart on Tweeter and have twenty companies who make perfume immediately pinging you, and all that, they are already doing that. Their answer is to deploy massive troops whose job is to sneak into your conversations. They adapted the same way China adapted to the Internet: growing their ability to sneak into the dialog.
  • “The software that will let them adapt is Social CRM”. Oops, fallacy alert! Yes, I know, Benioff needs something to energize his 1.1 company, and he is a brilliant marketer, and he can command the pundits and experts alike (who indirectly leave out of his crumbs), with a snap of the finger… but that’s just not what CRM does. CRM does not empower conversation… unless you are the salesperson; social CRM doesn’t change the nature of CRM, it’s just an attempt by the company to control your conversation… even as what “your conversation” mutates into a social discussion.
• Follow the leader intentions by the rest – Yeah, you already know all about this one
• Stale enterprise categories – Want boring? Want old? Want dinosaurs? Just look at ERP, CRM, CMS, all those enterprise software categories. Not only the tools are boring: the categories themselves are. How boring? Well, let me use an example from the CMS side: so boring that even a monolithic piece of architecture like SharePoint is called innovative… that at a time when everyone is moving to light weight ones. How boring? Have you ever used SalesForce.com, or Siebel, or …? If you have, I don’t need to tell you more. Where these vendors have already reached everyone that can be reached, Social Business Services vendors are just emerging, and are recognized as the best big thing. Wouldn’t you do the same? What, if I was in the business of selling horse-powered carriages, I would have changed my marketing too: I would be selling “SOCIAL carriages”. You bet!
• The failure of a model to evolve – You sell things that are all about control, manipulation, need-to-know, secrecy, walls and silos, “corporate controls”, and all of that. In other words, you sell CRM, or you sell CMS’s. You have a good business selling to the very old. The guy who buys from you wears suits and has trouble using even his Blackberry (yes, HIS). He is worried to see the conversation moving away… but you need to keep selling him. The irresolvable conflict between these two modalities is worth a separate post (where I will tell you, as an example, why “Social SharePoint” is another oxymoron, and yet for the same reasons), but its essence remains: CRM, ERP, CMS’s, they all excel at supporting all those structures of control and secrecy (I really mean it, they are EXCELLENT at it). I made a lot of money through my career supporting those mechanisms as well. It’s just that they are outdated: there is no slight coat of paint that will save them. Dinosaurs.

When you look at Chatter, for example, all there is there is a thin layer of social artifacts (the usual, discussions, posts, small groups of people, avatars, profiles) coming to the sales person rescue, helping him CONTROL the conversation a little longer; somewhere in there are you. You are now surrounded by other “influential customers” who are “just like you” (in prisons, they would call them snitches: you see, this “others like me” is not only a new type of social filter for information, it’s old enough to be built into your genes, it’s just that now even “they” know that); you are still the prisoner of the conversation (as determined by the asymmetry between the information YOU gain and control and the information THEY own and control). Does that sound like a new type of relationship to you?

What is that you just said? That it doesn’t matter because you, the user, don’t buy the software?

Yep, you are right… But notice that I didn’t say Benioff isn’t brilliant: on the contrary, he knows he will sell to ignorants as long as he steals a few concepts from that “other thing” called Social. Further, that reality is even OK with me: ignorance is its own narcissistic dictator, and, at the end of the game, everyone playing with it will succumb to it.

I just don’t think that Social CRM will buy SFC (and the ignorants) too much time, because in the meanwhile you are setting up your own social filters, your own BS traps, your own lie detectors, your own social smarts, much, much faster than SFC can spin this crap around. When that oxymoron  called “social CRM” shows up in your business transaction, you will recognize it for what it is: just another trap.

When you do, you will go back to the place where customers manage their relationships. It’s called social networks, and if companies are involved, it will be called Social Business Services. No need to contaminate it with the old dinosaur genes.

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Reason No. 2 why Social CRM is an oxymoron

Remember MCi and AT&T calling you 100 times a day? That was CRM at its ‘best’.

People who care about CRM are people who could care less about you, the customer, being helped. It just matters to them if you are influential in Twitter. Are you? I am not.

Who puts “Social” and “CRM” in the same sentence? CRM vendors. Usually, SalesForce.com, trying to pimp Chatter. There you have a great social relationship: the sales person that has been ignoring you ever since you bought that lousy product from them. Now he wants to know more about you, what your opinion is about this and that, in the hope he can sell you “that”. That’s how “social” this is.

Why is SalesForce.com also doing it? Well, they market an alternative to traditional CRM, and do it very well. Which, considering the competition, is not really a big feat. But let’s face it, they are good at that. However, have you ever used SF? If you have, compare it with a good social enterprise platform like Jive.

Yep, now imagine that quality of experience coming from SF.Com. Nuff said: if you don’t get it you haven’t experienced true “Social”.

So, I understand that SFC wants to bring some glitter into their tired, exhausted, anything-but-interesting set of customer-ignoring products. I understand that anything “Social” today glitters like gold, and there are way many gold diggers out there needing a revamp. So, I DO understand why SFC is talking “Social CRM”. Unfortunately for SFC, it still doesn’t make any sense.

If you disagree, I ask you to just take your pundit hat off for a minute, and put on your customer hat (yep, the same “C” on the front). Now go ahead, look at this oxymoron called “social CRM”. Go ahead, smile.

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Reason No.1 why Social CRM is an oxymoron

As I reported before, Evernote started becoming ubiquitous on my machines (I happen to use several, on different OS’s, as part of my consulting job). Having an always auto-synchornized, always up-to-date record of ANYTHING I wrote or pictured or scribbled was enough to convert me. Add to that automatic scanning of all pictures and formidable character recognition, one of the best (nimble) interfaces I have seen, availability via browser, lightning-fast search, solid clipping and tagging functionality, (recent) sharing of notebooks with other users, and you can understand why an Evernote notebook is ALWAYS open on ANY computer I am using.

Slowly but surely, EverNote took over space and timethat had before been devoted to other applications:

• Bye bye stickies, notepads, etc., because an Evernote note is for ever (never needed to delete one), and ubiquitous, and available wherever I am because I always have with me one of the devices that can be used to take “notes”, even if it’s by snapping a picture;
• Bye bye outlining and hierarchical notepads; outlines and hierarchies quickly grow out of manageability, and as a result become beautifully engineered but heavy maintenance structures. To make it worse, reality (or my understanding of it) drastically changes with time, and when it does the hierarchy I built does not represent it any more. At that point, I either need to spend a lot of my time to fix the structure, or throw it away. A simple indented list from EverNote is usually a good device, not only because it is intuitive to use, but also because it contains its own “recommended scope”: If the list becomes unwieldy to manage, I am over-complicating things, time to simplify. And, of course, it’s also (to all practical purposes) eternal and ubiquitous, and searchable and…
• Bye bye word processors. This one is a little unfair, because I have been trying to get rid of those ridiculously over-functional pieces of bloatware for a long time. Not that I have a problem using them, on the contrary, I am quite good with them, and have used them to write content pieces much larger and sophisticated than they were designed for. I despise them because they are huge, create false dependencies with form and presentation, are used as lock-in by Microsoft, tend to hog my computer’s resources, and make me write very, very long sentences justifying why I hate them. In any case, Evernote strikes the right balance of formatting by sticking to what you can format in a basic Web editor, which is a good balance for me. I am happy to say that I have not used MS Word for creative purposes for over a year: I only use it when I am locked in by someone else (i.e., needing to collaborate on somebody else’s file). Even if I do oblige (particularly with customers), I make sure the other person understands that I consider her choice of format a major pain. I wish more people did the same…
• Bye bye OmniFlow, iGTD, tiddlywiki and the other GTD applications that I have used through the years: I started using Evernote plus a simple system of specialized tags (@TAG for contexts, +NAME for people, and *PROJECT for projects), made those tags sub-tags of higher-order ones (@CONTEXT, +PEOPLE and *PROJECTS), and used them as instant synthesizers. I ended up with a GTD system that is not only first-class (it supports all key ideas of the GTD system) but also requires MINIMUM BEHAVIOR CHANGES in order to use, much less than using any of the other implementations
• Bye bye creating a separate content collaboration space with each customer (Usually done in Drupal): a shared notebook keeps us always up to speed, and the rest is overhead. This is an area where I believe Evernote could become a killer social application for knowledge workers, and the recent addition of sharing may mean that the very smart people behind it are looking into that. There is so little to add to the current functionality that I really hope they do.

Increasing encroachment is also taking place in my blog writing (this posting, as many others in other blogs, are at least drafted in Evernote, sometimes completely written in it) and other social writing.

Am I saying that Evernote is all of those things in one? Absolutely not. I am saying that, IF you are a minimalist like me, and value computer-independence, tagging, web-level formatting, and usability, Evernote has all that it needs to replace the minimum set of features in all of those applications, and then some more (like taking a picture of a business card and having Evernote turning it into a searchable contact record, or a library of all web clippings that really matter to you, and more).

How can you go wrong? Release registry and disk space, gain complete and constant (and searchable, and semantically taggable, and actionable, and web-publish-able) access to everything you write, avoid bloatware, and release meaningless time devoted to unneeded form to be used instead for creating…

Why am I writing then “a note is a note is … my brain”? Because “note taking” is a narrowly constructed phrase that deceives you about Evernote. “Note taking” is something you do while boring professors, bosses, clients and collaborators talk in the background, something you do as a quick solution until you get to a “real writing device and metaphor”, something you do it in whatever paper you have on hand (or my favorite 3×5 cards) but you know you’ll have to re-process, it’s always a means to a presumably higher goal. That’s deceiving.

When you know that every note you take will be always available, that it will integrate into your life in front of the computer, the phone, the PDA, the laptop with ZERO effort on your part, that you won’t have to remember it because tags and search will bring it to you, a note is not only a note and a task and a project and a document and a blog post and … A note is what happens when you write. Period. Any simplifictions you need to do to leverage them is justified and well worth it!

Because for me writing, speaking and thinking are inextricably linked, my note repository is starting to look like my mind’s mirror (Except the reflection remembers much better than the real one). I always tell people to whom I show Evernote that if the computer had been invented before steel, the first typewriter would have looked exactly like Evernote.

It’s actually ironic that a few applications before captured my imagination as potentially being capable to contain all my activities (Are you old enough to remember MORE on the Mac?). Many of them started as a “PIM”, other as outliners, others as databases, and then started layering layer upon layer of functionality on those “standards”. And now, here comes Evernote and makes me realize that a core of very well thought functionality, Web 2.0 and a truly minimalist approach were the right ingredients.

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

A note is a note is … my brain

A quick scan of enterprise feeds is enough to convince us that any company in the Web 2.0 space is about to shut down because of SharePoint’s presumably unstoppable momentum. And yet:

• Half of SharePoint users use it just as a file manager, not surprising, considering that that is the only part of SharePoint that users get for “free” with Windows Server;
• For SharePoint, social enterprise seems to be all about having wikis, blogs and a MySite page for each user (which can be expected to be the focus of SharePoint 2010), whereas most social enterprise leaders like Jive are already moving into what Kathleen Reidy of the 451 group calls “use cases, not tools” which in other words means real solutions for innovation, brand management, customer relationships, and more, as opposed to the possibilities opened by tool kits;
• Talk to any SharePoint implementation partner, and you find that by far most of the money spent in SharePoint projects is going into basic content management functionality, from extending search to be able to manage run amok SharePoint 2003 silos to getting workflow to work, and not into all the things that supposedly make SharePoint so “dangerous for E2.0 vendors”;
• The fact that most crucial business workflows are already managed by incumbent CMS’s like Documentum and IBM FileNet (and woven into it very strong content dependencies) is not frequently discussed, which is dangerous, because the most attractive bells and whistles in SharePoint only shine when SharePoint has omnipotent control of all content.

I suspect that such a gap between reality and KoolAid sweetness will take a few years to settle (Microsoft is putting s lot of fans into creating the dust storm). When that dust settles, I suspect the landscape will look like this:

• A content management layer where SharePoint will coexist tightly with other multiple Content Management silos;
• A basic team collaboration set of services, perhaps complemented with equally basic expertise location and small scale social snippets (and yes, very squarish and SilverLight-ribbon-heavy MySites);
• A thin coat of partner paint, delivering supplementary web parts (the same ones that Microsoft will deliver as “good enough” web parts in the next release) and trying to stay away from the proverbial elephant;
• A thriving layer of social, enterprise 2.0, solution oriented innovators that use all of the above as a source of content to feed interactions, activities, semantic knowledge, innovation management, brand management and many other Enterprise 2.0 functions;

I am sure there will be companies that implement the whole thing using Microsoft’s stack (who doesn’t like to be featured  in every Microsoft brochure and presentation, after all?) but the business transformation that Enterprise 2.0 requires will not be built like that: business just can’t wait for Microsoft…

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

The SharePoint buzz

• The MiFi is the killer enabler for netbooks-like computers;
• The netbooks have miniaturized to the point where they are becoming to use a keyboard and/or a good screen at the same time
• The Windows tablet is horrible, but an Apple one, with an iPod / iPhone interface would be awesome
• The iBlet (like the name?) is the drooling dream of anybody using iPods, iPhones, Macs, and quite a few Win-zealots

If it happens before September, send me a cookie. If it’s called iBlet, send me an email and I will send YOU the cookie.

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Is there an Apple tablet in the way?

Don’t blame me for being buzzword-agnostic: twenty five years in technology are enough to kill buzzword sensibility. Perhaps I should clarify that rather than agnostic, the right qualifier would be antagonistic: it’s not that I don’t believe in buzzwords, it’s really  that I believe (and know) that they end up used for inflicting much more damage to reason and the collective IQ than benefiting it. The 2.0 postfix is no exception. Wired-to-tired.

From a wonderful way of grouping equally wonderful technologies that empowered hyper-connected users (as if such a demographic really needed any further boosts beyond those of wealth, class and education), the 2.0 ‘thingy’ got increasingly appropriated by young X-ers, who wield it with the same acumen as a scalpel ready to castrate anything “old”. 

Social networking is technically 2.0. Hard to disagree with that, just look at the technology and functional stacks, right? Well, yes, in principle, but not necessarily in execution… Trace the Web 2.0 technology stack back a few years, and you will find that early users of the term were, and most of us still are, in love with concepts such as the semantic web, topic maps, ontology, semantic meshes and much more as the true inspirational forces justifying a technology refresh; the 2.0 technologies were just early moves in those directions. And yet, try to find anything substantially semantic done beyond tag clouds and better online usability, even in social networks and collaboration products, and there is very little to show for it (the truth is, semantics is not a trivial game to be played by a handful of AJAX and WS hacks in a few agile iterations).

But that is OK, I guess, technologies and paradigms (oops, as an old friend used to say, wait for the word paradigm to emerge and then leave the room really fast)  take time to mature. The problem is, in the meanwhile, 2.0 got hijacked and became something else. Web 2.0 is

• Young, specifically, generation-X-er. If X-ers do it, it’ll take the world by storm, and it’s archetypically good. By default, you are old if you don’t do it. And of course, the fact that you don’t do it is bad. Take twitting. You may be just humble enough to know that infinitesimal changes in your state of mind don’t matter more than the noise of cars in the freeway to others. Or, you may be the kind of person that needs long, quiet, contemplative moments of inspiration and concentration in your daily routine, away from twitts, toots and tettes. Because of any of those reasons (many more available), you don’t twitt. You are old. You are (like I keep hearing from so many beautiful, 2.0 people) “so 1.0-ish”, or “so 1.0!” for short.
• Anti-restrain, anti-hierarchy, anti-confidentiality, anti-structured. By association, any hierarchically, control-based, structured collaboration system is 1.0. Protection of intellectual property? Corporate liability? Compliance? Management structures? Project management? Accountability? Nah… don’t bother
• A vague, increasingly threatening, ad-hominem attack, one that is accepted beyond PC-filters and netiquette. You can find it wielded in reverse (as in “this that I am saying would be just another unproved and unsubstantiated generality… but wait! I am an X-er, I have been around 2.0 all my life, so I don’t need to be rigorous”)

And all of the sudden, strange things like “Enterprise 2.0″ are engendered. You can read postings from very articulate and intelligent people (some of whom I have in my RSS list), who start to fly away from reality and talking about bringing FaceBook into the corporate network, and start announcing the funeral of Office (specially spreadsheets, so structured, so 1.0 ).

Uhhh? I don’t know, call me skeptic, or perhaps it’s that I am “so 1.0″… But I’ve been around a zillion of 2.0-like iterations, seen their fizzle go up and down, and when the dust clears, 1.0’s are still around, yes, irreversibly changed for the better, but still around. From mainframe to PC to LAN to Client-Server to networked computers to n-tier to … (can keep going at least for four more lines). Every time, the 2.0 would eliminate the 1.0. Yet, I know that there quite a few PDP-11s still buried in the organic systems running mission-critical applications out there (how about flight control computers? or nuclear monitoring apps?). Don’t believe it, OK, let’s replace them with those so-long-ago-extinguished mainframes, or PL1 programs, whatever.

The truth is, not only 1.0 turn out to be much more resilient than expected: 2.0 tend to have quite a lot of weak spots as well (how else would we sustain the next iteration?). Ad so, the 2.0s get looked at, taken apart, deconstructed, resisted, imitated, plagiarized, even perverted, by wise practitioners of the 1.0. In the process, some memes and genetic material gets lose, like a fine pollution, just like polen, and spread around the crevices of the 1.0… The rest of the ecology parable is easy to imagine…

So, call me 1.0-ish, but I know that change, REAL change, the one that change peoples’ lives, doesn’t happen in 2.0 waves, but rather 1.1.17 ripples. Today, tag clouds are as far as it gets, but hey, you can find tag clouds even in mainframe apps. Web services are starting to permeate all existing systems, and now even mainframe apps have gone beyond encapsulating a Cobol routine into WS wrappers. Like tides, each one of those cycles got organically deconstructed, and a few memes and genes stayed around for good

So, I am not interested on disqualifying the old just for the sake of it. I have no presumption that radically new ways of doing things will put the old to rest. I am skeptical as it relates to such profound transformations. Instead, give me concrete, benefit-bound memes that we can insert into every-day people’s routines. Yes, Office apps are SO 1.0… but you know what? Hundreds of millions of users use them every day, in most cases not by their own decision. So, can your wonderful, 2.x app do away with the need for Office? That is great, I truly believe it can, and I am sure at some point, many years from now, it may (I even helped conceive a few such apps years ago).

In the meanwhile, PLEASE give me a way to save those hundreds of millions of users headaches when they want to edit an Office document from ANY Web 2.0 app, and I will get really excited as well; I can’t avoid it, I am very 1.0, and I am growing old… I just can’t get off from my mind the thought of giving millions of people a happy second or two. And you will have contributed to the next iteration, Enterprise 1.1.17.b, not an easy feat…

More important, by not alienating ‘the natives’, we will have managed to increase 2.0’s chance of growing into an unstoppable tsunami. Remember, I didn’t say that I don’t believe in those wonderful 2.0-ish thingies. On the contrary, I am just getting irritated by the irresponsible BS and prepotence that slow them down by creating antibodies faster than infected cells. 

Be well, in peace  :)

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Intelligentsia 2.0

Like many other practitioners before her, Lisa found that when it comes to enterprise collaboration, there is a huge difference between wanting to solve a problem and knowing what specific product features are relevant to your needs. In other words, if you want, say, “to empower collaboration in order to create alignment between highly distributed teams in order to improve the product cycle”, how does MySite functionality help you? If you want “to increase intimacy between partners and internal stakeholders”, is that something a blog, a wiki or a forum will produce? How relevant is a forms server to collaboration?

The thing is, it’s common to start requirement discussions these days and immediately start hearing from stakeholders “I want a blog/wiki/community/forum/tweeter/your-Web-2.0-buzzword-of-choice-here”;  everybody wants to jump into it, whatever that is, because the benefits of Web 2.0 technology are presumably very  compelling. The question is, are those benefits the ones you are after? Is your organization ready? And so on…

It is very rare, however, to get an articulated statement of need that goes from specific use cases to correlating common collaborative patterns inside the organization with the functionality needed to empower it and enable it. Add to that the pressure from vendors to define the field (which is in the middle of a land-grab period)

What Lisa was asking was some sort of basic semantics and ontology to start moving away fro the “wants” towards the “we need… because…”. Basic thought blocks… A basic functional taxonomy.

Of course, there is a ton of pre-digested stuff that I could (and will) point her to, matrices after matrices of basic function points, usually provided or ’seeded’ by vendors in the category, talking about portal management, forms, business intelligence, types of content supported, and so on. I am sure we will get to those at some point, but first we need to agree on basic “thought blocks” for us to manipulate and discuss as we approach her requirements.

On the personal side, I find myself going over these basic elements over and over, because this is a very common stage of collaboration projects, so I decided to put some extra work at it and construct a basic  taxonomy to use as a starting point for future requirements analysis with my customers (hopefully, everybody wins). I will improve the taxonomy after I write this article, and use it as a skeleton to tag and classify content in this site as it grows

The basic framework

There are many ambiguities in the definition of collaboration-related terms, thanks in great measure to the efforts of vendors to re-define the world in terms that fit their products (as opposed to the other way around), as well as the broad extent to which the term is applied (e.g., intellectual collaboration between several individuals and collaboration between countries). Nonetheless, a common-sense approach to understanding collaboration requirements makes some of those ambiguities irrelevant by

1. looking at how people in a given company have traditionally collaborated, 
2. identifying recent changes that affect collaboration  
3. extrapolating the above to understand what is needed to support and empower collaboration today

To avoid distractions produced by huge hype campaigns, over-anxious vendors and the infinite wave of convergence that produce one presumably revolutionary device every week, each one enabling equally presumed revolutionary collaboration capabilities, let’s start with traditional collaboration concepts (1960s to 1990s) whose validity is not bound to recent technologies. Once we agree on some basic building blocks for the concept, let’s keep building on it until we reach a satisfactory “present” status, and only then let’s speculate on what tomorrow will bring. 

The basic concept of collaboration

As for the word “collaboration” itself, let’s define it for now as an iterative process followed by multiple individuals,  all of them sharing a common goal or mission, in order to:

• Share their private knowledge and access others’, which is usually done by sharing and interacting with content (i.e., mediated knowledge, knowledge represented as content) as well as by  communications between individuals conducted via conversations, messages, collaborative editions of documents, etc. (i.e., conversational knowledge);
• Explore and discover possible scenarios and alternatives related to the common goal;
• Develop consensus about reality and courses of action (usually making that consensus permanent and more shareable by creating new content).

The definition above is quite operational, and is particularly effective inside corporate environments because it is generic enough to allow for multiple “flavors” of collaboration, from the more structured, control-driven ones (e.g., performance analysis and review sessions) to the more decentralized, socially centered and conversation-focused ones (e.g., strategy brainstorming).

If we were to simmer that definition even more, we should arrive to the fact that people collaborate by interacting and working jointly on knowledge, both conversational and mediated.

Simplistic collaboration patterns

Basic collaboration patterns emerge as soon as you put a group of knowledge workers in the same location (“working jointly” used to require being in the same place), make sure they use some set of basic artifacts that most of them are used to, give them intersecting objectives (that is, the success of one influences the success of others), and give them time to develop their own routines.

The individuals will soon reach a balance between individual (private) work and collective work, the later conducted by meeting somewhere, bringing with them the content and other artifacts they need for the task at hand, and collaborating (sharing knowledge, exploring possibilities together, developing consensus). Given choices, they will like to maintain close relationships between them, so that as new elements come up during projects, tasks, workflows and such, they can address them through ad-hoc, further collaboration. 

Finally, as they become more familiar with each other, individuals will develop and/or further multiple types of relationships amongst each other giving place to a myriad of specialized networks and sub-networks (if you like graphs, think n-tuple meshes). As the number of those networks grows, individuals will represent them (besides explicit lists), by attaching characteristics to individuals “profiles“. In layman’s terms, the group of Community Sponsors in your company may be represented by a list of the thirty or so individuals in it, as well as a variable in each user profile called Community role, which for those 30 individuals will have the value of “Sponsor”. 

In that simple context, collaboration happens as those workers start all sorts of interactions and collaborative activities supported by work artifacts (schedules, calendars, tasks, workflows, processes) and in the process consume and create many types of content (messages, recordings, presentations, documents, etc.). When they are not meeting, those workers will be working (alone, or in different meetings, on the same artifacts and content).

Personal networks will operate in a somehow “orthogonal” yet crucial plane relative to the other elements, by acting functionally as a selector (which networks participate in a particular collaboration), but more important yet, acting structurally to represent corporate groups participating in crucial corporate processes that are enhanced by collaboration. The  process that matches both functional and structural networks is crucial to the ROI for social collaboration.

The simple collaboration model described so far works only in very constrained circumstances, in which:

• workers are co-located (or near-located). That is, it is simple to move between the private workspace (where they work by themselves) and collective workspaces (where they work with others);
• they share a common contextual understanding of the task at hand;
• the participating individuals have relaxed agendas, so that most events can be performed in a synchronous manner (i.e., all participant are available at the same time for mutual interaction – a phone call, a meeting, a conference), as opposed to asynchronously (i.e., participants conduct their own activities at different moments in time – store-and-forward activities such as email, voice mail or any other type of messaging, editions of a document that are performed with persistent locking of versions, etc.).

Some of the key concepts identified above are directly correlated to ECP’s functional layers:

1. Individuals and groups (which will be usually translated to “users” of the collaboration platform and “networks”)
2. Artifacts that are used by all individuals, such as calendars, process diagrams and workflows, location and presence indicators, identifiers, etc.
3. Content, which are documents and other file-based representations of knowledge used by individuals
4. Channels of communication between individuals and groups
5. Interactions between individuals and their common and private knowledge.

More realistic patterns

Enterprise workers today work in conditions that rarely include collocation, social integration and synchronous collaboration; rather, enterprise workers today…

• Are hyper-connected to data networks (more frequently, to more networks, with higher bandwidth) and they use it to generate massive amounts of content;
• Have lots of computing power to spend for assistive technologies (like most of those in Smart Phones);
• Are (increasingly) used to technology-mediated interaction technologies, as well as devices and modalities, and have relatively low resistance to behavioral changes required to incorporate them;
• Multi-task intensely, and are usually involved in a multitude of projects, each one in connection with different groups, objectives and processes;
• Find themselvesy distributed across geographies, time zones, even languages;
• Are NOT socially integrated, but are instead increasingly process-integrated by back-office corporate applications (this is equivalent to saying that knowledge workers now interact not only with other knowledge workers, but also with applications and automated processes);
• Use an increasing number of devices, as different combinations of connectivity, memory, processing power, storage and interaction bandwidth are brought to market in convergent devices;
• Generationally, growing number of knowledge workers are increasingly subject to “Web 2.0 expectations”, which project current experiences with convergent devices, mobility and other interaction technologies to predispose them to try technology-assisted collaboration (and accelerate adoption in the process).

These circumstances represent both challenges and enablers to collaboration, and have been at the root of many industry movements to address them (knowledge management, business process integration, content management, document management and more). ECPs are therefore not radical, new technologies, but rather a confluence of older technologies and infrastructural conditions that were not present before, and which come to be known as Web 2.0.

Challenges to collaboration

• Geographic distribution and thin time slices mean that synchronous activities require a lot of assistance from technology in order to still take place, this time in virtual workspaces, whether it be a web-based conference or a presence-enabled call that is automatically routed;
• Personal availability for synchronous activities is reduced by orders of magnitude, and scheduling becomes proportionally harder. As a result, multiple modalities of asynchronous knowledge interaction emerge to replace synchronous ones (each of them creating its own management and integration challenges) and presence management becomes critical for communications;
• Group maintenance activities become overwhelming when the number of working groups multiplies; even keeping in mind the context of each group becomes almost impossible. As a result, the administrative functions related to collaboration grow more and more complex;
• Collaboration becomes yet another activity mediated by applications (collaboration platforms), creating resistance (“I already don’t have enough time, don’t ask me to do something else”) and confusion (too many interfaces between systems and individuals); extreme ease of use and seamless functional integration will become crucial to avoid failed deployments;
• Teams are rarely socially integrated, which means that each project has the potential for participants needing to re-develop basic trust and capabilities understanding. As a result, assistive technologies for relationship management become more important (still a very immature science, reduced to basic reputation management and relationship initiation support);
• The massive scale of most global enterprises, the content they create, and the number of individuals they involve requires innovative discovery, sharing and consumption mechanisms for knowledge and individuals.

Enablers of collaboration

• Ubiquitous networks make location more irrelevant, facilitate most virtual meeting interactions when combined with presence and other assistive technologies  (synchronous advantage)
• Convergent, and more intelligent devices make it easy for workers to utilize time slots that would otherwise be wasted, interacting in relatively new but highly productive modalities;
• Lots of extra computing cycles can be “wasted” in assistive technologies, such as voice, natural language, semantic layers, rich presence and location, and so on;
• Many routine activities related to tasks, auditing, record-keeping, and more can now be performed by systems without human intervention;
• Content integration brought about by Web 2.0 makes it easier and easier for workers to collaboratively create content and weave into it personal interactions of all sorts, reducing process friction and at the same time empowering richer, more complex documents (but at the same time contributing to the “content avalanche”).

In a nutshell

When we factor these new constraints and enablers into our definition of collaboration, out definition of what a collaboration platform needs to support do not significantly change. Collaboration platforms will still need to manage users, groups, artifacts, content, communication channels and knowledge interactions; however, in order to address the challenges above, collaboration platforms will need to:  

• deliver many different types of virtual workspaces on demand and in an ad-hoc manner, 
• facilitate the discovery, sharing and utilization of knowledge resources, 
• enable streamlined and unobtrusive communications via multiple channels and modalities and 
• support collaborative activities across all workspace activities, which requires making collaborative services available to back-office applications as well. 

However, collaboration platforms need to support those elements in a manner much more agile than traditionally done,

• leveraging technology and networking to replace physical proximity and laxer time availability, 
• creating assistive technologies that improve management of groups and networks (i.e., social networking),
• automating administrative tasks via shared calendars, project management, tasks, etc., and 
• addressing the issues created by the massive quantities of individuals, knowledge and interactions involved.

Factoring patterns into meaningful functional blocks

The challenges and opportunities above have created the conditions for solutions that enable modern knowledge workers to collaborate productively, which we will call Enterprise Collaboration Platforms (or ECPs for simplicity).

From a functional point of view, ECPs consist of several crucial components, which together deliver the experience of collaboration as introduced in the beginning of this article, and which can be described as conforming a layered functional pyramid:

Core Services

Core services unify and standardize (to different extents) knowledge workers’ access to all the core application behaviors, metaphors,  involved in creating the user experience. In terms of the succinct definition of collaboration that we developed in the beginning of this article, core services do most of the “heavy lifting” needed to support users (i.e., knowledge workers who can access the ECP), artifacts (by containing and/or integrating to the servers that allow those artifacts to be discovered, created, shared, modified and managed) and groups (i.e., multiple typed relationships between any number of users):

• User Management – All services that allow knowledge workers to access and use the ECP, including user authentication, administration, user directories, Single Sign On, etc.;
• Group Management – The creation, modification and maintenance of groups of any number of users, related by a common typed relationship (e.g., “is a participant in Project X” or “all content moderators outside of the company”, and such), and surfacing of those relationships via rich user profiles and attributes;
• Artifact Infrastructure – Servers (or interfaces to servers) that enable users to create, instantiate and use artifacts such as calendars, schedules, workflows, structured data (databases), phone calls, instant messages, and other objects of collaboration that are not directly correlated to files.

End users do not typically “see” or interact with the core services layer, but those services permeate the complete platform, and enable all users to access and use the same artifacts and services (user differentiation based on function access is implemented at a higher functional layer) as they collaborate. 

As you advance towards your requirements document, you will find that this functional block contains most of the IS- and IT-oriented use cases and requirements. Depending on your internal power structure, you may see systems that exceed the requirements in every other functional category being “shot down” because its core services don’t align well with IT’s environmental vision. 

“Rich” Relationship Management

Collaborative relationships are characterized by very large number of possible types of relationships, potentially as many as there are nuances that are important for people to relate to other people. From “people who like bicycles” to “taoists’ to “commuters” to “married” people to… the list is obviously close to never-ending: users of a collaborative space are connected by a very large of “typed” relationships (it’s not just a single type of relationship). If you were to represent it as a graph on paper, you would probably end with nodes (points, little circles) connected by a massive number of lines of close to infinite lines, of almost as many different kinds (e.g., colors).  At this point you would be approaching a “mesh”, a complex graph of very specialized properties.

There is line I don’t want to cross in this article, that of discussing architecture (I am not qualified), but the fact is that the traditional representation of using records representing users, with fields for different types of relationships (e.g., “Likes bicycles”) AS THE ONLY WAY to represent social relationships very quickly breaks down in implementation, as the records in question become “wider” (i.e., the number of relationships increases).

We will visit the specific requirements that can separate simplistic relationship management from rich relationship management in a separate article. For now, let’s state that there is a fundamental difference between true relationship management and the simplistic association of a few relational attributes to users.

What about Document Management?

Depending on which vendor you ask, the core of EC will contain more or less support for desktop applications and the documents they produce, in the form of Document Management; Microsoft, for example, with a vested interest in making MS Office even more of a standard than it already is, and pushing other technologies into the enterprise into the process (both valid competitive aspirations), has a heavy bias towards tight integration of MS Office applications into the Enterprise Collaboration platform (SharePoint WSS and MOSS), and thus has made document management the core of their EC product, because given the dominance of Office, that really means Office-document Management.

But such close relationship between desktop documents, eminently private in their creation, storage and management, and Enterprise Collaboration need not be the case. In “pure” Web 2.0 collaboration scenarios, all documents can be online documents with shared access (a wiki page, a posting, or a whole wiki), and full-blown collaboration can be reached without the user ever touching a copy of Word or Excel, or if she does, leaving the detailed document management outside of the scope of the collaboration product through common attachment mechanisms.

Which side you sit on, it’s a matter of opinion and religion. My recommendation to practitioners is to consider document management as complementary, but external to the collaboration system. I do that for two reasons:

1. Manageability: Because of the need to guarantee availability, resource consumption, application provisioning, compliance problems, and a million other reasons, desktop documents are much more of a management problem than online documents, with little added benefit. Further, collectively created content is usually much richer in context and knowledge than ultra-formatted private documents that contain only one brain’s output. Call me an optimist, but I believe that IS and LOB managers will realize these facts and increasingly move to online documents, as opposed to desktop ones;
2. Vendor tie-in:  I always recommend to customers to reduce vendor tie-in, not to increase it (which is a particular case of a higher end rule, that of not sacrificing independence of opinion and choice unless there is an absolutely life-or-death reason to). As a consequence, I always recommend on the side of keeping Document Management outside of the realm of EC (and proprietary document formats as well), building seamless conduits for documents to make it in and out of the collaboration platform, and avoiding private desktop documents as much as possible. That means that yes, you will occasionally need to import into your EC environment a few files that are part of special processes (e.g., mechanical design) or that are used as interface between your organization and others (the usual spreadsheet or slide deck), but most other documents should be kept as richer, shareable, continuously updated web content.

The three pillars of collaborative workspaces

The three columns introduced below each take care of three key collaboration objects: knowledge, communications and content.

Knowledge Management

This group of functions allow individuals and groups to represent, access, integrate, share, publish and consume knowledge, by leveraging different models of interaction and organization, whether it be wikis, blog, forums, micro-blogging, shared-note-taking, application-sharing, white-boarding, co-creation and co-edition, or any combination thereof, whether executed synchronously or asynchronously.

Knowledge is increasingly represented by meshes of objects (nodes and users) and large numbers of typed relationships between them; to accommodate this representation, this layer also includes knowledge management artifacts such as taxonomies, semantic tagging, synonym and glossary management, topic maps and ontologies.

Also critical to knowledge management is the representation of individuals’ trust and expertise, as a critical qualifier of knowledge; therefore, the knowledge management layer also includes (or in some cases should include) assistive technologies such as reputation management, network mapping and analysis automated relationship management for users. 

Typical functionality delivered by the knowledge management column include:

• Content interaction models – Asynchronous models reign today (Wikis, blogs, forums, chat, twitting, mobile note-taking), but synchronous modalities are also being explored with interest (e.g., simultaneous co-editing, white-boarding, others). Regardless of the results, the list will probably keep growing, as different interaction modalities are explored, and standards for the core models will emerge;
• Knowledge representation and discovery services – Semantic tagging, tag clouds, smart tags, topic maps, ontologies and other abstraction technologies  that improve on the limitations of flat text and links by automatically (or collectively) creating metadata about content, and thus facilitating its management;
• Expertise location – Assistive technologies that assist in finding not only the right piece of knowledge, but rather the right resources that may be used (i.e., instead of finding an article on item XYZ, find the person who writes the highest rated articles on XYZ and semantically related concepts).

Communications Services

Support for fluid communications between knowledge workers and/or themselves and/or applications, utilizing transport-based channels operating in both synchronous (VoIP, chat, conferencing, IM, etc.) and asynchronous (email, SMS, RSS feeds, streaming, faxing, multicasting, etc.) modes. 

In the previous paragraph, the inclusion of applications as participants in communications is not accidental, but rather crucial, as more and more components of corporate knowledge is managed directly by automated systems: the capability to integrate those information channels into the collaboration system is a crucial capability for collaboration (e.g., your group may want to make sure that data from your SAP or Oracle applications can seamlessly integrate into collaboration processes via web services, and that setting up such flows is as simple as possible).

Despite the fact that today’s commanding communication modalities are text-based, a quickly growing number of technology-assisted interaction modalities and channels will almost certainly change that, balancing text-based interactions with other types, most of them mimicking person-to-person interactions, but some of them originals in their own ways (e.g., twitting). Each modality in turn carries with it artifacts of its own (filters, feed subscriptions, buddy lists, etc.), which can make channel proliferation more of a problem than a solution.

Functionality that falls in the communications layer includes:

• Synchronous channels: Chat, desktop conferencing (voice, video and converged);
• Asynchronous channels: Email, RSS, notification services, unified messaging, etc;
• Web services: Capabilities required for integration of application data into collaboration processes;
  
• Contextual communication artifacts: Ability to initiate multiple possible channels of communications with specific individuals wherever mentions of those individuals is made (e.g., contextual menus in Outlook wherever a recognized user smart tag is displayed, including calendar info, telephone numbers, presence information, email addresses and such, all of them “live”). Also, unification of multiple communication modalities under “smart client” applications, in order to reduce the complexity introduced by too many communication channels to master and control;
• Other artifacts and services: Additional services that are needed in order to maximize the contribution of communications to collective knowledge, such as recording, playback and podcasting, participation and delivery tracking, filing, conversion and indexing, subscription and filtering, channel convergence and switching, and much more.

Since communication is so crucial to creating knowledge, it would be expected for a corresponding level of support by Enterprise Collaboration products and platforms. Unfortunately, that is not the case: even for mature channels such as email artifact management is very poor and spotty. That creates several adoption and implementation problems, as users have to learn and internalize different gestures and usage patterns for different channels, as if they all were different processes, when in reality they are ultimately all producing the same transfer of information across space and time. That is probably the reason why, for example, a very valuable communication mechanisms such as NetMeeting was part of Windows for years with minimal usage and impact (now in the process of being removed and replaced by a more generalized set of services).

There seems to be increasing awareness about this problem in the part of vendors, as reflected by the hype around unified communications, unified messaging and such, as well as by early awareness about possible “interaction platforms”. Unfortunately, vendor interest is almost certainly more related to gaining a seat in the banquet devoted to devouring the spoils of analog telephony (a.k.a. ‘unified communications’, UC2, etc.) than produced by an interest to advance the state of the art in communication standardization.

Content Management

This functional block supports all activities and workflows related to content discovery, access, creation, storage, sharing, modification, distribution, archival, publishing, and consumption. I use the term content with its generic meaning of “contained information”, making no explicit distinction between on-line or desktop containment, structured and unstructured, single- or multiple-file. Such wide definition follows my approach to this taxonomy: when people collaborate outside of the Enterprise Collaboration platform, they may use a statistical table, a picture, a beautifully formatted document, or a piece of music to collaborate. The same should be possible in enterprise collaboration.

As with communications channels, the coverage of different types of content by different content management functions is quite uneven: while 70% to 90% of corporate content is said to be unstructured, only structured data stored in database enjoys wide coverage. But the movement to standardized levels of management regardless of content type (i.e., towards the “content platform”) is being fueled by more and more stringent compliance requirements, and hopefully will become reality sooner than the “interaction platform”.

While waiting for the emergence of a unified content platform, there is one distinction between types of content that remains highly disruptive for collaboration platforms, that which separates desktop-stored content (from office documents to sound-casts, video, multimedia, collaboratively created content, CBT, and more) – which reside usually in individual computers – and online content (e.g., wiki pages, blog posts) that reside on servers. The characteristics of both types of content are very specific: while desktop-stored content is private, application-specific (and in many cases proprietary as a result), of linear flow and using fairly elaborate formatting, online content is shared, somehow not-application dependent (through the use of common tagging languages such as textile and its derivatives), possibly enriched by strong hyperlinking and non-linear flow, and simpler formatting. The distinction is quite important to the product selection process because Microsoft collaboration product, SharePoint, puts special emphasis on Office documents as the unit of content, whereas other collaboration vendors such as Atlassian, JIVE, and others excel at managing sophisticated and rich online content (with IBM somehow in the middle). 

The distinction, however, will grow increasingly blurry, as desktop alternatives emerge that deliver the best of both types and are identical across the desktop-server divide (See “Evernote: New collaboration modality?“), without the need to preserve proprietary differentiations. 

Column Dynamics

Convergence

We have said that the core of collaboration is people sharing, accessing and interacting with each other, as well as with each others’ knowledge; in real life, those activities are closely intertwined, and in some cases indistinguishable. For the same reason, the lines between the three functional blocks above sre not always clearly delineated: the three categories keep weaving into each other and converging into each other. Because of that convergence, some services, tools and infrastructure components participating in ECPs are hard to classify, and will become increasingly so. Particular examples are conferencing (collaboration and communications), presence services (communications and collaboration), unified messaging (Content and communications), etc.

Channel proliferation

As channels and collaboration modalities keep proliferating (and in most cases entering the enterprise via sneaker-ware – consumer adoption by its knowledge workers) collaboration platform vendors are faced with the need to integrate management of the new channel or modality into their products or leaving it outside of the collaboration process. This makes the planning process increasingly difficult; in general, the best response is to avoid single-vendor lock-in and favor standards-based approaches (easier written than done, unfortunately).

Context Services

Context Services is the functional block most visible to users, and a visible differentiation between enterprise collaboration products; this layer creates maintains for users a workspace metaphor that anchors those users’ experiences into a certain context, or perspective. Those contexts are equivalent to views into a database: many virtual views can be implemented based on the same core data, all of them different. That is particularly the case with EC products (which are, after all, database applications), because the context or metaphor used for collaboration is highly influential upon the type of collaboration that will result (if any).

Workspaces are the experience of virtual spaces presented by ECP’s to users, as a way of providing a physical metaphor that can both make the collaboration experience more intuitive and at the same time anchor other services (and specially the artifacts that represent them) in a common metaphor. For example, in social-centric workspaces usually favor views of the system centered about the user looking at them, her previous activities and her choices for the things she wants to be presented with. In document-centric workspaces, preferred views are those of sites where lists of documents, users and/or artifacts are presented, and collaborative-content-centric views favor rich views of content available for access. Finally, future “workspace 3.0″ work currently going on (the term is mine, and arbitrary) is creating virtual reality workspaces where the commanding metaphor is physical, and where artifacts somehow try to leverage physical metaphors as well: the artifact for a phone connection in such a workspace is the 3D representation of a phone. These “views”, just like database views, are totally independent and arbitrary, and not usually exclusive.

For example, if the main “view” (or context) for a given system is implemented as activity- and project-based workspaces, with strong ties to task management, calendar, GANTT charts, and milestones, that project-centric view will influence strongly how users leverage the system, and will to a great extent determine the user interface as well, which will become technical, centralized, hierarchical, with lots of controls (many attributes are important in project management) and unforgiving as it relates to lack of precision. A conversation-centric workspace, on the other hand, will clusters its functionality around relationships, friends, conversations, discussions, issue discussion and consensus, and such. The user interface may become much simpler, and the view for the user will be almost certainly self-centered even when still concerned with her activities, contacts, on-going tasks and so on. In one, the user will feel part of a structure, in the other she will feel the center of the space.

Considering that enterprise collaboration products are still quite immature, the current state of affairs as it relates to supported collaboration contexts seems to be either-or. It is common to read and hear from practitioners that “SharePoint is document-centric”, “Clearspace is conversation-centric”, “Confluence is wiki-driven”, “Connections is activity-centric”, and so on.

Today, when most collaboration products are benefitting from the hype surrounding collaboration to fight for territorial expansion (as many customers as possible, as fast as possible), each vendor touts the success of its selected context as proof that it is THE context that makes sense… but is that necessarily the way to go? Couldn’t or shouldn’t all collaboration products support ALL of them?

I believe (but have no way of supporting the opinion) that ultimately all collaboration products will support ALL contexts for collaboration, including some that are not generally available yet outside of specialized domains (e.g., virtual reality worlds used for online games).  I take my clue, again, from the way normal collaboration works: supporting only one modality would be equivalent to a person saying “No, I am sorry, but unless we follow strict project management methodology i will not let you help me wash the dishes”.

Some of the key functional categories delivered by the context layer include:

• Workspace management: The ability to instantiate new workspaces in an ad-hoc, planned and/or automated manner, populate them with adequate artifacts, communications channels, workflows and content resources, and maintain them for as long as needed, preserving their state across time in the process;
•  Templates, workflows and components for quick initialization of particular types of workspaces, based on the purpose of the collaboration (i.e., team meeting, light project management, consensus-building discussions, documentation writing, etc.);
• Best practices to enhance collaboration around common functions and processes;
• Roles and responsibilities support, through the automated creation of content structures and personal workspaces that reflect common needs of users with well known 

The contextual layer is the “magic” one in the collaboration stack, because it creates the “illusion” of co-location and synchronicity, even if individuals are continents and time zones away from each other. The trick doesn’t need to be detailed and immersive from a virtual reality point of view: we are all familiar by now to the intense emotions that can be experienced while reading a posting in a discussion forum or wiki, even if we have never met the other person, or know much about her: to the reader, she is present while he reads, no more or less than if they were in the same room.

However “magic”, it’s important to note that virtual workspaces are just starting to evolve; by any standards, today’s workspaces are primitive and cumbersome to use, based mostly on text, and mostly serial in workflow. Most of these limitations are caused by the limitations of today’s “universal” thin client and the lack of vendor commitment to “playing by the rules” of already available standards (specially for communications, such as XMPP, SIP, SIMPLE, etc.). As those limitations are eliminated in the next ten years, workspace metaphors will:

• Abandon today’s myopic attachment to emulating narrow-band interactions (just like the traditional example of building over-dimensioned steel bridges that sank under their own weight, just because all engineers knew was how to build with wood);
• Deploy assistive technologies and artifacts in standard ways that may become intuitive to all (as opposed to having to hunt all over the user interface to find the correct widget for the interaction modality that the user has in mind). 

At that point, EC products will start to realize their very unique potential to give birth to massively distributed collaboration, supporting collaboration at a scale, scope and demographics that are not nearly possible in co-located cases (i.e., “massively distributed collaboration”, a term coined by Mitch Kapor). I personally believe that, despite all the energy and attention wasted by the early hype on the transformational power of the Internet, massively distributed collaboration does have the potential for significantly transforming culture and society, and ECPs will carry those transformations inside the enterprise as well.

Collaborative Application Services

Despite the strong focus on end-user services, the “golden pot” of ECPs is the integration of collaboration services into back-office enterprise applications such as SAP, Oracle Apps, etc. I have already described as an attribute of the content layer the ability to bring into collaborations data from those app: this functional block reverts the direction and makes it possible for collaborative workflows and services to be intertwined into the operation and workflow of back-office applications, creating in the process hybrid applications.

The power of such hybrid collaborative applications was validated many years ago, as IBM rolled out Lotus/Notes as the first true enterprise collaboration product. Soon afterwards, users started leveraging and implementing Lotus/Notes integration into back-office apps: according to recent industry surveys are one of the most critical barriers to switching to other collaborative platforms for most users still holding to Lotus/Notes, despite willingness to do so. Not surprisingly, Microsoft’s is very busy promoting similar integration capabilities in their Collaboration Platform, and trying to create IBM-to-Microsoft migration scenarios in which the collaborative services of one are replaced by those of another.

The collaborative Application Services (CAS) later is defined in terms on integration points, API’s and web services that can be used to selectively invoke collaborative processes from other applications, using multiple client types. Thus, the important attributes of this layer are programmability, architectural separation and customizable behavior, transforming the individual components and services of the EC product into a toolbox to be leveraged by other enterprise applications.

Effectively, the CAS functional block marks the dividing line between enterprise collaboration products and enterprise collaboration platforms, because this layer makes it possible for collaborative activities to become part of the workspace, regardless of process or activity, as opposed to a distinct activity that users conduct.

Summary

The result of this exercise is a first-order taxonomy that looks as follows:

Enterprise Collaboration

• Core Services
  • User Management
  • Group and Relationship Management
  • Artifact Management
• Supportive Services
  • Knowledge
    • Content interaction models
    • Knowledge representation and discovery
    • Expertise and resource location
  • Content
    • Integration
    • Discovery
    • Access
    • Creation
    • Storage
    • Sharing
    • Modification
    • Distribution
    • Archival
    • Publishing
    • Consumption
  • Communications
    • Synchronous and asynchronous channels
    • Web services
    • Contextual communications artifacts
    • Other artifacts and services
• Context Services
  • Workspace Management
  • Templates, pre-defined workflows and components
  • Best practices
  • Roles and responsibilities
• Collaborative Application Services
  • Standards
  • APIs
  • WEB Services
  • Protocols

In a coming article, we will take it from here into more detail. Also, the writing of this taxonomy made me realize how immature the collaboration market is (and my understanding of it as well): I found it infinitely more difficult to try to create an abstract taxonomy than addressing the need with a pre-defined scenario in mind, as when I go over requirements for a collaboration deployment with a customer. As a result, I expect the taxonomy above to go through several improvement passes, and I would welcome your input in the matter.

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

What are the basic elements of Enterprise Collaboration?

From what I hear, most collaboration vendors are trying to tackle this problem, some by making the desktop edition even more proprietary (guess who), others by trying to improve RTE’s. Well, there is another vendor, one that doesn’t have a collaboration platform of its own, whose product (Evernote) is quite relevant to this issue…

What is your workspace vision?

I have been pondering about the competing notions of “workspace” implicit to different collaboration products and companies. Here are a few:

• The ultra-unified collaboration and communications story (i.e., Microsoft’s, Cisco’s, IBM’s) – All of these visions start from the pragmatic assumption that the Microsoft Office apps are around, and will be around, as the standard desktop environment, and then imagine the workspace as this virtual space where people meet to collaborate around the artifacts they have produced in Office. Emphasis: mostly private authoring, with a collaborative icing on the cake. Not surprisingly, Microsoft promotes this vision of the workspace where you and I meet to discuss a PowerPoint deck you produced, and in order to work on that .ppt file, we would use chat, SMS, IM, VoIP, conferencing to bring in Mary’s opinion, and so on. That workspace vision is very natural to people who still spend forty or more hours a week in conservative organizations dominated by Windows, where each PC comes with Office and Explorer (and practically nothing else outside of the occasional VPN), and where most of the work is done individually, by individuals. On the other hand, if you are an occasional user of Office (most SMB’s, small virtual teams, most creatives, and so on), and you have come to dread using it because of its over-featured characteristics, you might found that scenario very limiting. Further, even if you are a frequent Office user, you may (like me) fear the sheer accumulation of synchronous and asynchronous communications modalities (phone, VoIP  phones, IM, SMS, email, voice mail, presence-enabled clients, automated assistants trained to find you, and so on; I don’t know about you, but I already have more interruptions that I can handle, and more communication modalities that are comfortable to keep under control… So, in a nutshell, Office-artifact-centric collaboration workspaces are a natural, possibly more productive, extension of their networked desktops of today for intensive Office users, and somehow convoluted and overwhelming to people who are not, or who have their quota of interruptions already full. SharePoint supports, creates and maintains archetypical Office-artifact-centric workspace. Because SharePoint (both WSS and MOSS) are here to stay, the Office-centric workspace model is sure to get a long list of adopters for years to come (we will discuss in another posting whether that is good, bad or neutral for collaboration progress);
• The collaborative-artifact-centric workspace (Atlassian, WordPress, most open source CMSs), which is harder to find usually because the workspace concept itself is downplayed (but still there in the form of “spaces”), where users collaboratively work on documents they collectively produce, whether the collaboration has an opportunity to start from inception of the document (wikis), following a central thread of postings (blog) or triggered by “questions” or “issues” whose resolution is important to many people (forums). Whatever the publishing model, this workspace model does not put so much emphasis on people talking on the phone, holding conferences or sending and receiving SMS and email, all while they write on the wiki, and therefore adoption patterns for this type of workspace are quite dynamic and persistent. The collaborative content is the center of attention, and users mostly are something close to a second thought. Atlassian’s Confluence, for example, is a great example for this modality of workspaces, as are WordPress MU for enterprise blogs. Before you object, telling me that SharePoint also supports the modalities above, I must preemptively answer that wiki, blog and discussion support in SharePoint is minimal, primitive and barely enough to make that statement of support, and also that despite the accumulation of several servers brought about by MOSS and the layer after layer of functionality (user profiles, SSO management, etc.) it still remains an Office-artifact-centric workspace manager (I have even stronger opinions about the usability of the communication pieces, but that will wait for another occasion). Let’s just agree for now that collaborative-artifact-centric workspaces are characterized by strong focus on collaboratively produced (and immediately auto-published) documents, with users as a somehow secondary-priority object, which is there mostly to create, serve and maintain those collaborative documents. To make justice to Confluence, I must say that there seems to be a recognition in Atlassian’s part that users and their own personal experiences should be more relevant, but the transformation has not yet completely taken place. In any case, this type of workspaces are specially attractive and productive for technical users (whether technical means computer-savvy or some other specialty); that is the case for many reasons, prime between them that collaborative documents are usually much more complex structurally than flat Office documents because of hyperlinking (Office supports links but it doesn’t make sense to put links to files that are in your private disk, or have to go to SharePoint to find the URL of something else – not for now), macros and plugins that allow the representation of many types of objects in the content (from workflow, to relational data, to media, to…), and also the fact t hat many people together think much better than a single one, and therefore the collectively produced documents they originate are much richer and interesting. On the other hand, this type of workspaces tend to irritate Office-only users (a large percentage of today’s users), for whom bold is control-B, tables are (a) a menu on the top right and (b) indispensably finely tuned and precisely colored, titles and other styles are carefully crafted by font, size, font style, etc. It would be unfair to say that those things cannot be done in this type of workspaces: the problem is that those things are done differently, and asking people to use a browser-based Rich Text Editor or textile (*bold*) is already asking too much. I am amazed when I talk to collaboration experts and some minimize the importance and size of this population, as if it were made of sick people, and I remind them that (a) at least 4 out of 5 CEO’s fall in the category, as well as an even higher percentage of white collar personnel and (b) many people learn to use a computer by using Office applications… and never need to go any further;
• The user-centric workspace, where the focus is carefully kept in the user itself, by “personal workspaces” containing artifacts related to anything that that user has going on at the time. Those artifacts may include blog posting, discussions, Office documents, and any other type of document and/or media, as well as tokens and avatars of other users, brought into the personal workspace by their participation on any of these things going on for that user. A very popular representative of this vision is JIVE Software’s Clearspace, as well as IBM’s Connections (when put together with other IBM products).  A typical landing page for a user-centric workspace is the personal workspace, where the user finds notifications about updates to documents she may be working on, articles published on areas she has interest on, users she is friend with who may have new contributions, and so on; as the user follows any of those links, she will enter other people’s workspaces, as well as group projects, and in the process land on content documents, either privately or collaboratively produced. User-centric workspaces have the attraction of focusing (by definition and architecture) on the things that matter to each user. It is not uncommon for any two different users to have totally, radically different views of the same collaboration hub, because each one of them configured his/her private space to show precisely what they wanted to see and do. Even when the notion of workspace is radically different, social networking collaboration hubs complement document-centric ones quite well. Except for issues of Single Sign On, Unified Search and simplified access to content across environments, there is usually no procedural or process-oriented regimentation to maintain, because the content-centric and the user-centric workspaces serve the same user at different times, for different purposes; I may use my social networking site first thing in the day, to plan my day and update my knowledge about things I care, just to continue one of the threads in it into a content-centric collaboration where I may work for hours in MS Office, or vice-versa, and my interest will drive me naturally to the correct workspace hub. The characteristic of a user-centric workspace is, then, that the focus of attention for the user is her own state of work and collaborations, as well as other users that are actively participating in them; only from there do users usually access documents to work on them. Another strong typifier of such products is that other users, as well as the networks they define (networks, team, buddies, etc.) are at least equally visible, and finally, that such user visibility brings with it a corresponding highlight on user interactions themselves (and in most cases even more) than content objects (there are other technical differentiations of such products, but I am concentrating on Workspaces for the moment).

Of course, the abstractions above are separated by thin and ambiguous lines, and you can expect to see them crossed constantly by products. But they are also good tools of analysis: I have found that most requirements documents for collaboration products quickly zero into these variables.

Workspace patterns

So, we can see that several patterns emerge as we differentiate philosophies of workspaces:

I have productively worked with (and in most cases deployed across an enterprise) most of the modalities above, and several combinations thereof, and found them all attractive and productive, each one on its own capabilities and special applications. I have also found that any product exhibiting any combination of the parameters above can be a productivity sinkhole when used in the wrong manner; that is the case because all of the products I mentioned above as archetypical of one modality or the other also manage to “almost do” what makes the others archetypical as well: using them in that “almost as good as” manner is an almost certain disaster and waste of time.

The gray zone between private and public content work

I have also found that  there is a corner of my way of working (with emphasis on my, just because I don’t know if its yours as well) that is not covered by any of the modalities outlined above, and that is the corner where private note-taking overlaps with online collaboration. When I tally the time I spend working on the computer, I realize that a major chunk of my time is spent clipping, gathering, writing, annotating, organizing content by myself, on my desktop, privately, even when the content I clip, gather, write, annotate and organize comes from the web, email, wikis, etc. and is, in most cases destined to become part of a collaboration.

The problem is, when the moment comes to use that content in a collaborative fashion, a major usability fracture emerges: that of re-purposing the “private”, carefully integrated multi-source content into on-line collaborations I may be working on. I call this corner “the moment of taking my brain store public”, and if you have attempted it, you hate it as well:

That’s why I have been an avid user of OnFolio, until Microsoft bought the company and killed the product, then OneNote  (until I settled on Evernote for Windows), then Notebook, Omnioutliner, Caboodle and about ten other apps in the Mac (until I settled on Webstractor, a fantastic app that proceeded to become unsupported when the vendor died and immediately proceeded to bomb while saving in OS X 10.5), then several notetakers on my S60 phones, and so on… All of them imposed the heavy price of making the private notes public that I described above…

Well, NO MORE! Now there is a new Evernote for Mac, combined with a new hosted synchronization model, that I believe will shock the world, and in the process help solve a significant part of the pain caused by one of the discontinuities that has most troubled collaboration products (and a big hush-hush for those products, except for IBM who has a relatively slim advantage in the area): the chasm between offline and online content. Whether because you travel on site and have no access to the VPN from your customer’s network, or because you spend two hours working on the train getting to and from the office and home, or spend too much time in airport, the fact is, your private knowledge and your collaborative knowledge are sitting in different places, one on your machine, the other online… and you are always bound to need the one you have no access to!

Evernote to the rescue, rocking the world

I hope you tried or used Evernote at some point on Windows. Talk about a neat, clean, superbly designed product. It basically sat in the status bar, ready to be invoked at any time, and ready to receive web clips, copy/pastes, selected chunks of graphics and/or text, hand-written notes (switching to hand-writing if you were using a tablet),and so on. You never needed to save, if you clipped it or wrote it or annotated it, it was permanent. Then, you could highlight, add to it, delete, edit, etc., and still love it more.

If that wasn’t enough, Evernote had something that looked almost science fiction, even for OCR-savvy users: it would process your handwritten notes, or pictures of signs, or whatever pixel-based, and turn them into searchable text! Did I mention that the search in Evernote was lightning fast already? I am sure you are logving it by now… No? Ok, consider this: tagging of notes, categories, a ticker-tape metaphor for chronological display, templates, c’mon, you’ve GOT to love it! OK, OK, you could buy it for $39, do you love it now? No?

If no, it maybe because there were a couple of problems with the Windows version:

1. Did not run on Mac (Ouch!)
2. DId not do much (actually, ANYTHING) to solve the private/public thing…

So, it was still by far the best note taking app in the world, but it fell short…

Until I found out about the Mac Evernote beta. The mac version is, as anything Mac, sexier and neater than its Windows counterpart (albeit a little less functional yet). But hey, it solves the multi-computer thing (because there is also a version for Linux and phones –sort of). That is quite nice, but the private-public thing…

YES, IT SOLVES THAT PROBLEM TOO! And it does it through a feature that makes it infinitely more powerful than it was before: a hosted model through which notes can be synchronized between an online store and different computers, accessed online at any time, and SHARED with other users online as well.

Wow, are you starting to see the possibilities? And… did I mention that the online version of a note you see on your browser is identical to that in your computer, the one where graphics, tables and other niceties looked so well? Or that you can also edit it ONLINE? Or that the client version runs on Windows, Macs, phones and Linux? Or that you can send a quick email with notes from your phone and they will become notes? What about pics in online-synchronized notes being automatically tagged with their contained, searchable text?

The possibilities for this product are UNBELIEVABLE, and I hope you see what I see… Let me outline possible scenarios:

• Evernote decides to sell the server as an enterprise collaboration server, where people share some of their notebooks (Evernote’s personal workspace metaphor), and enable collaborative content (all that lays in the way is a simple authentication and granular access control mechanism);
• Remember that notebooks can contain ANY KIND of media, including voice annotations (directly from your phone), videos, etc, each one of them procured in the device that makes sense to you in the moment. This is intrinsically more UNIFIED than anything in the mega-monolithic UCC vision by Microsoft… with one millionth of the footprint, and leveraging personal devices without heavy weight IT budgets!
• Now that your ultra-flexibly produced private notes are online, with nice formatting, graphics, and such, why would you use convoluted mechanisms for attaching documents, then referring to them? Yes, there will still be Office content, but I can guarantee you that many, like me, will get rid of most needs for Office and STILL share nicely organized and formatted content online. I will spend a large amount of time taking light-weight but rich-enough notes, knowing that if I am online my content is synchronized as often as I want, and if I am not it will when I get back on line (and that I carry a fairly actualized copy in the meanwhile).
• Evernote notebooks will keep adding richer and richer mechanisms for clipping, annotating, etc. I can see a point coming where it can match the mind-boggling fidelity of clipping that Webstractor used to have, and the PDF-to-RTF correctness that other Mac products have, and the intra-page linking beauty of Voodoo Pro, etc. The richer the desktop mechanism, the richer the online verison will become, without additional pain of any sort. All of it automatically synchronized…

The perfect condiment

I realize that my excitement may come as out of place to most of my audience. Unless you have worked, and DO work, with several collaboration platforms, on a couple of computers or more, you may think I am exaggerating: even if you have experience note taking you have not experienced the pain of transferring to online collaboration platforms. Yes, if you use .Mac you will share the excitement for good synchronization (which is not a trivial problem to address any way), but still… only if you have experienced the pain of sharing your private notes in a collaboration platform you will sympathize.

Now, if you DO use at least one workspace-based collaboration product, and you DO take notes, clippings, cut-paste, etc., try it and stick to it until it starts synchronizing. Once it does that, try installing the client on another computer. Now share your notes… YOU ARE HOOKED, this is an awesome thing.

Now, there is a possible company play I don’t care much about, which is Evernote trying to become the world center for all notes (As you read above, what excites me is the possibility of a server you can acquire for internal collaboration). Well, not less than a week ago the company posted user quotas (limits) of 40 MB per month. For a company that (presumably) wants to be the Google of notes, the number is a real joke… but the potential for an enterprise collaboration move is still there, and that is still cool…

Getting a beta for Mac

You can go to the Evernote website and request the beta. The problem is, it took me a couple days for me to receive the user ID I need for the hosted component. That tells me beta subscription is quite limited… but I have 18 invitations left from my membership, drop me a comment if you want one, and I will send it out until I run out of them. You’ll love Evernote, and you’ll like me for it.  :)

Nota Bene: [Correction] When I wrote the original article above, I blamed Evernote for leaving previous users of the stand-alone Windows note-taking app hanging dry… Well, it turns out that I was wrong, and I am happy to report it (See Phil Libin’s comment). My apologies for the short-lived slander  :)

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Evernote: new collaboration modality emerging or just note taking?

•  Huge advances – Not a buzzword any more, collaboration will be one of the most important IT concerns for 2008, and has fierce grass-root adoption at the consumer level;
• Confusion – Now that it’s proven as a valid concern, collaboration has been wrapped together with too many other concerns, specially some coming from the communications side, and it’s easy to lose perspective of what is real (collaboration) and what is fodder (the always-hyper-connected workforce, communicating in twenty different channels and modalities at the same time, and at the same time having time to collaborate productively).

Here goes a timed perspective, from my eyes and memory, of some of what has happened in these last eleven years.

1997 — Technical Collaboration… uhhh?

In late 1997, as a VP of Marketing for Starbase, I remember customers’ and media’s skepticism and resistance when we “audaciously” used the new term of technical collaboration to describe StarTeam; “Since when is source control a collaboration issue?”.

People who were not users, and did not “get” StarTeam, would look at the threaded discussions that were part of the product, and their eyes would glaze, trying to understand what the heck was a discussion doing in the middle of so much source code. Some times, we could tell those people “Look, you can tie together the source you produce and change, with your discussions and comments about it, then you can use those discussions as threads to understand changes”, and in one out of five cases people would get it.

The same would happen with tasks, project management, and other “superfluous” team collaboration mechanisms that were surfaced through the product’s user interface; people expected a technical product to be… well… technical, and “collaboration” was not something techies did. Then again, that was 1997, and “techies” were just coming out of generations of changing applications using COBOL, one copybook at a time… Perhaps all that was needed was time to go by?

2000 — Communities and Reputation Management

Fast-forward to 2000; collaboration had become hot, specially between developers. During a very short six months or so, I was assigned to try to help create one of the first hosted development environment for corporate and open source developers (yes, the two terms don’t make sense together, and that’s probably why it didn’t work out); the venture was a spin off Starbase, located in Scotts Valley.

Think about it, collective, hosted, collaborative development, all very progressive concepts, just at the dawn of open source… Who would say that collaboration had not arrived? 

Just before jumping on board of the new venture, I had been dabbling with my friend Pierre on the issues of Communities and Reputation Management (through a couple of early community portals called VoteZone and Grapevine respectively, both of them experimenting with community and reputation management strategies, both of them piloting the user-centered approach to content that has now come to be called social networking).

In the process, I had become first seduced by the potential of massive collaboration portals, then nauseated by the asinine waste of energy produced by anonymity and large clouds or flaming bozos and robots, and finally elated by the capability of good reputation management to maximize the first by controlling the second; all that remained was just for massive collaboration (now called social networking) to start happening, and new wonderful things to evolve from it… It didn’t take a rocket scientist to understand that reputation management was a basic pre-requisite to civil behavior online, in the way to online virtual societies… Right?

So, I thought that it would be a good idea to bring reputation management into the hosted development environment… It just made so much sense, considering the social outlook of hosted collaborative development!

Did the acceptance of technical collaboration bring about tolerance and understanding for reputation management? Did social concepts pile up neatly as bricks, or did each brick need to be justified on its own? Did I succeed? You would think so, but you couldn’t be further from the truth if you tried.

I remember bringing Pierre to our offices, so that he could discuss with the two leading technologists in the company (let’s call them Jason and Jeff, to simplify)… J&J, bright and progressive as they were, two bright kids who believed themselves to be ahead of the pack as it related to collaboration, cooperation, and the social potential of the Internet, spent two hours fighting against the idea, and never gave themselves a chance to understand it.

It was a really sad meeting to attend: for Pierre and I, having experienced the power of reputation management first hand, the discussion was not about whether it made sense, it was just how to make it happen as fast as humanly possible; a total no-brainer!  Anything else would be equal to a world where everybody uses the same mask, the same voice…

But J&J didn’t even want to understand what reputation management was about; collaboration was a sticky buzzword, anybody could see that it was a good thing, but nobody wanted to get into the details of how to enable it, and this reputation management thing sounded like it required true discipline and thinking… Collaboration couldn’t be that hard, could it?

In other words, collaboration had undergone a long journey, but only the buzzword had established itself as something that “made sense”. A few practitioners had developed working, vivid experiences, but they were at that point just anecdotal book material, stuff “that other people do”; nobody disputed the power of collaboration, but some people were still fired for trying to get it to work…

2005 — Communities, wikis and blog — The practitioners’ challenges

Another fast forward to 2005. As a brand-new consultant for a $1Bn software company, I am asked to put together a business initiative for a platform and business process to support a ”cloud” of external user communities (with a projected maximum number of over a hundred individual communities, most of them for users of a specific product, others clustered around specific industry issues important to the company’s customers).

The initiative was clearly articulated (I will summarize the most salient points in a separate posting), approved after 30 minutes of review by the executives… and then buried two or three levels below anybody who could give ANY meaning to the phrase “executive sponsorship”, the sine-qua-non of successful communities. 

Not surprisingly, while buried, not much progress was made in the communities front; but a few things started happening in a parallel front, internal collaboration, where I was kept busy  rolling out an internal R&D collaboration platform, using Atlassian’s Confluence wiki platform and Sharepoint.

Sputtering, with many vacillations, internal collaboration started to happen; many content structures and workflows were started, some of them dwindled, but some prospered, and soon the “breeze could be felt” as we moved towards the tipping point. Having been involved in several such projects in the previous few years, I must say that despite the lack of an internal collaborative culture, budgetary support or executive sponsorship, this tipping point came much faster, with fewer hiccups, and in an obviously more sustainable manner than previous ones, even when the preceding ones were better positioned in those three critical fronts (internal culture, resources and sponsorship).

Pure luck? Perhaps… After all, I always preferred to be lucky than good. But the key component, which was not there before, was the awareness about collaboration and web 2.0 on the part of the users, and a desire (almost an impatience) to give it a try. Collaboration had already sneaked into their collective subconscious, it wasn’t just something that could be done and was good, but rather something that was being done, and why shouldn’t they? I must clarify that  I am not talking about a leading bunch of bleeding-edge developers of web 2.0 platforms, but rather average corporate developers, mostly developing database applications, and IT operations management tools: as representative a sample as can be asked of the median US developer population. 

On the external collaboration front (communities), after months spent customizing JIVE Forums, doubtlessly the best community product available (and the one with the most robust reputation management functionality), so that it could manage hundreds of independent communities, things were still sputtering.

This was 2007, and I was asked to help revive the project; by then, ten years after we used “technical collaboration” at Starbase for the first time, and with collaboration shining always brighter and brighter, you could expect both projects (external and internal) to have been smooth sailing, mostly routine…After all, these are the times of collaboration, right?

Of course, you would be wrong again if you were too optimistic; but not by as much as before. Sure, “executive sponsorship” ended up becoming “lukewarm tolerance”; “hundreds” of communities shrunk to “a handful of very small groups” as soon as it became obvious that communities required corporate, executive and participant commitment; and most people didn’t even get it: just as I right this post, as an example, I got an email from somebody inside the company who has worked all along in the communities initiative, asking me to clarify –for the hundredth time in three years — when do people use a wiki, a blog, a forum, why, and what for… 

Yes, it wasn’t as great as expected. But on the other hand, thousands of page views a day on the knowledge base, close to a hundred individual contributions a day to the wiki, healthy metrics in all communities, and such, meant that despite apathy, internal politics and lack of direction people who want to collaborate found a way to do it, once they had the right tools and infrastructure.

One thing is for a company to have a “friendly” environment, another totally different is for it to have a “collaborative” one. But one thing is certain: take a friendly environment, make a few good collaboration tools available, and some collaboration hotspots WILL appear. And they did: pockets of collaboration started happening, brewing and interacting amongst themselves; collaborations started taking place, and nobody was surprised when it happened (or, more critical yet, challenged because of it).

Nota Bene: On the subject of “friendly vs. collaborative“, I believe that one of the most insidious challenges faced by enterprise collaboration is that executives in “friendly-culture companies”, who know nothing about collaboration, somehow believe that people in their company already do collaborate (“After all, this the most friendly company I know”), and because they think so they quickly reject the idea of investing on it (more on this in another posting).

In any case, between 2005 and 2007 I saw collaboration become part of the workplace landscape; actual people, inside a normal, perhaps just slightly more conservative environment than could be expected in a large company, where using collaboration day in and out as intuitively as they would use a phone. Just something you do, and of course, something you want to do with the best tools possible.

In those three years, I also grew the realization that *enterprise* was more than just a qualifier for collaboration, that it is its own thing, something related to collaboration but not just a flavor of it (I will write about that later). I saw many companies going through the process of implementing collaboration inside the enterprise, collaborated with several of them, and realized that it was just a matter of time (actually, a year or two) before it became as accepted as email is today…

2008 – The target keeps moving

This year (i.e., 2008) should be a record-breaking year for collaboration; everywhere I turn, I talk to companies where collaboration is the next big roll-out, taking place *now*, in 2008. 

Knowledge architects, managers and executives in companies that used to call me every few months trying to fetch new arguments and to convince themselves to get going, are now in advanced deployment of collaboration platforms and tools.

Collaboration went from niche activity (only for techies) to visionary business goal, to tolerated “fuzzy investment”, and it’s now entering the status of *basic need of all knowledge workers*. But somehow, in the process of becoming a standard fixture, it got a little fuzzier.

At first collaboration was about getting people to *work together* across geographic fractures, time zones and systems, *working together* was just that, sharing a few artifacts, creating temporarily permanent spaces where to contain the results of their work (even if it was a directory in a file server), looking at a common page together and calling it “state of things”.

Then, web 2.0 platforms such as forums (JIVE Community Server), blogs (WordPress), wikis (Confluence), social networks (Clearspace) started to hit, and collaboration started to be characterized by workspaces (permanenet or ad-hoc), “where” teams would collaborate (there is no real “where”, but it’s a “where” nonetheless), would create content together, discuss, enact simple workflows, log activities, perform simple GTD or small-group-agile-task-management, where attachments could be the report you were looking for, and you would find them by navigating a tag cloud, or by locating with some degree of effort the expert on that subject covered by that report, and so on.

The issue moved from what collaboration was to how to better combine all the different ways that knowledge workers do collaboration.

• Is it a blog, a forum, a wiki, a page, a portal or a database? YES
• Is it social, reputation driven, profile enabled, expert-locating, intranet, extranet or medianet? YES
• Is it work, is it play, is it conversation, is it social, or is it just a waste of time? YES
• Is it unified collaboration, unified communications, or unified collaboration and communications? YES

 Not surprisingly, the soup is confusing. A ferocious hype storm, fed by the chance to reap a chunk of the trillion dollar telco market by reinventing (retro-inventing?) telephony as data, is now converging with the very legitimate running train of collaboration.

The results of this hype confluence is, of course, more hype, more confusion, people talking about huge stacks of software, servers, network components and telephony layers as if they were a system (which they are not, they are just a soup of systems, but not organic in the sense that telephony has learned how to be).

Not surprisingly, early adopters will be burnt severely because of their optimism, but in the whole nobody cares, because the hype storm is raging.

It is dangerous for collaboration, a market that has grown slowly for so many years, solely because of its own merits (there were no IBM’s, Microsoft’s and Ciscos pushing wikis or collaboration up to 2006, were there?). It is dangerous because it is been attached to grandiose big-bang visions of complete technology stacks that go from the hardware all the way to the apps actual people use, and in all directions in the organization, to encompass all activities they conduct today (or may dream to conduct in the future).

Grandiose, all-encompassing visions are usually the fruit of megalomaniac egos (personal or corporate), just another twist in the world domination fantasy. Those small groups that laboriously, sometimes almost clandestinely, managed to create collaboration hot-spots, may see them extinguish as many IT drones fall under the seduction of “automatically managed presence”, “VoIP network self-optimization” and the like, and those drones start implementing pervasive and intrusive communication channels that few people need across all layers, start intertwining them with back-office applications (so that you can now have the immense pleasure of talking to a voice enabled server to try to explain to it that your access to some system is blocked), start bothering the hell out of everyone in the name of collaboration.

But it could be good, also, if communications modalities that people do use get seamlessly integrated into their collaboration workspaces. After all, clicking on my name where it appears under a posting of mine on a wiki, to send me a message immediately, seems to make sense, doesn’t it? It could be good if those that have not even given a chance to collaboration (those that reply with an email to a voice message all of the sudden find themselves doing it, not even knowing they are doing the collaboration thing.So, it’s confusion time. The right ingredients are there for hugely successful collaboration efforts, and also for huge failures (which will probably be blamed on the “inmaturity of collaboration” when boards need heads to chop after them).

Considering how much is at stake, I’ve decided I will start writing more posting about this issue, hopefully one a day, to try to clarify my own confusions and in the process help somebody as well. For now, let’s leave it at this precariously optimistic point, where eleven years of trying to enable and foster collaboration seem to start bearing fruit…

Post from: Online shared intelligence; copyright © 2008 Carlos Caballero. All rights reserved.

Enterprise collaboration: huge advances, some confusion