by Paula Thornton
June 29, 2009 at 3:07 pm
· Filed under Enterprise 2.0, Enterprise Social Computing
I’m interrupting a couple of pieces in progress, because this topic is too significant to wait on. It raised its head as I was listening to a great panel discussion from the recent Enterprise 2.0 conference, facilitated by Peter Kim, featuring the Social ’stuff’ experiences of Allstate, Jet Blue and Humana. One caveat, as with all 2.0 conversations, it’s important to separate the B2C and C2C-focused examples from other focuses (B2E, E2E etc.). There’s a heavy B2C/C2C slant to the discussion.
Ben Foster from Allstate made two great comments:
Enterprises and practitioners are often guilty of using Social Media as a cure chasing a disease.
We’re moving past the experimentation stage…
There were many more great insights shared as these companies find their own ’success’ around these technologies. There was something between what was shared that scared me — a repeat of the evolution of IT: fostering isolationism — reinventing silos. One panelist even mentioned the word “silos” but I believe his meaning was in transcending organizational (or other) silos via open conversation. While conversations may be more ‘open’, they’re only as ‘open’ as the application or format by which they’re bound.
This is an old issue — one I posed to Bill Gates circa 1990 (when he was the ‘guest speaker’ for nearly every event in Seattle, and common folk had direct access to him). I asked him, “When are you going to separate the files you create from the applications that create them?” His response, “I don’t understand your question.” He didn’t wait for me to explain either. The main issue: the things applications create are ‘locked into’ the format of the application that creates them.
Blogs and wikis provide specific formats to content. There are behavioral format clues that differentiate a blog from a wiki, but under the covers it’s all content. Content elements have value beyond the formats and applications that hold them hostage — they’re enterprise assets that can be repurposed in other formats. The specific format of content (.pdf .doc .html) is really only relevant for consumption — to associate the ‘viewing’ of the content with an application that can display it. The semantics of the content itself doesn’t really care about the format (don’t hold me to that when I’m telling you how to create semantically-relevant formats), just ask your favorite search engine — it’s all words to them.
The significance and potential power of a format-agnostic architecture is evidenced in the recent demos of Google Wave. What we don’t have are the corresponding ‘drivers ed car crash movies’ to illustrate the disastrous end to conversations that are locked and isolated in disparate tools and formats.
Sadly, the significance of a well-architected application platform was something that was understood by the designers of Ventura Publisher, which applied format to the content via SGML — text, graphics, etc. were all managed in their raw form, and ‘assembled’ into the desired presentation format — in 1986. These were some of the same people from Xerox PARC who created the original graphical UI elements that Microsoft and Apple later fought over in court.
Consider a simple ‘hostage’ example (one that I’ve been aghast as many UX designers have missed the significance of), a UI with the labels “Blog” and “Wiki” as two separate options for navigation. If I’m looking for something (pick anything), which one should I look at to find what I’m looking for? You may suggest that I use the search feature (conveniently bypassing the original design issue altogether). This would have to assume that search constantly indexes all the conversations in real time — the results are typically grim, adoption fails.
Clearly, Microsoft contributed to ‘isolationism’ again with SharePoint — everything all neatly packaged in individual projects, with no ability to ‘watch’ for redundancies or facilitate cross-fertilization of conversations (ignoring for a moment that ‘conversations’ weren’t really supported anyway). And as David Armano pointed out in a Harvard Business Press post today, it all requires a healthy dose of seeding, feeding and weeding along the way (the continuous wetware element that IT rarely accounts for).
Sure, 2.0 technologies can increase transparency across organizations, but that’s all lost as you move across ‘closed’ solutions or formats, with no architectural layer to synthesize it all. One silo is simply replaced by another.
To capitalize on the potential of Enterprise 2.0, there has to be a total architecture that considers the full lifecycle and use of content, as it is leveraged for action (the part KM missed).
Permalink
Thanks for this thoughtful assessment of the situation (and the blind spots – reminds me of the expression that fish don’t know they’re swimming in water…). It seems to be yet another field/ground issue.
People just want to easily get on with communicating, working, managing, telling stories, raising awareness, recruiting volunteers, etc. and the tools are there to do that – so long as you remember to use the same shovel to fill the hole that you used to dig it…. The commercialization of the software and the competition for market share, ensures the results you describe. Kudos to open source for keeping the options available to all of us.
You could say that silos are lateral, too. I am working to bridge the generations within the community benefit sector, ensuring the continued capture of the knowledge capital of our elders who are edging towards retirement. The disappearance of a layer of middle-management as funding decreased over decades, has left few who can mediate a succession process, leaving the younger social entrepreneurs and empassioned staffers (highly tech-savvy, tweeters) to keep the sacred fire burning. Enthusiastic and energetic as they are, they are in the ‘gaining experience’ phase, and the price of this can be burnout and isolation. These folks are finding each other and creating community and support through social media, especially with small organizations where staff don’t share physical ‘real time’ space with very many colleagues.
There are certainly geologic layers in terms of comfort zone and ability to take the time to tackle these new tools – a mystery to some of us, with elements that seem to change daily. As a result, the transaction costs of learning seem too large an investment of time and energy. The focus tends to be on the confusion of the jargon/shorthand and resentment of the ‘in-group-ness’ of those who use, and it can be hard to see the usefulness. It would be helpful if those who are marketing the tools spoke as clearly to the typewriter-to-keyboard generation as they have to their peers.
In this scenario, it helps to have people thinking – as you have – of the bigger picture, the great masses of end users, many of whom are ’self-taught’, and what it feels like to them to have to navigate extra silos when the work they do is important, and could be made so much more efficient if there were a more ’seamless’ way to use existing technology tools, and to make the choices and transitions necessary to keep up with emerging tools. When all you see and hear are the others using the media, it is possible to have a distorted view of the overall population’s access and ability to make use of it.
Thanks for the ‘food for thought’, it helps me in my work to translate the language and minimize the angst felt by some – not all, by any means, don’t get me wrong! – of my fellow elders and mavens who have so much to add to the conversation, and to learn from it, if brought in.
There are a number of things worth commenting on here, methinks.
One thing that I thought was striking about the #e2conf this year (as opposed to last year, in my own experience) was the balkanization of the “conversation”. If you go read all of the various post-conference writeups, a theme emerges that is really quite fascinating — it’s almost as if the majority of commenters attended two different conferences. At the one conference, things were dominated by the vendors, and the “slant” of things was heavily B2C/C2C. At the other conference, things were dominated by users, talking to one another, and the “slant”, if any, was towards internally facing, intra-enterprise usage. I attended (and spoke at) the latter conference. When I look at the folks that apparently attended the prior conference, what strikes me is how little (if any) overlap there was in our schedules. I didn’t attend any of the sessions those folk did. They didn’t, by and large, attend too many of the sessions that I did.
IOW, I appear to be observing your silo problem, in effect at the conference. 
And that allows me to segue into my deeper reaction to your post here — I’m not sure, but it seems to me that you might be conflating two different things: content and wetware. You make quite interesting (and, in my opinion, correct) comments about both these things here, but seem to be implying, by the tone and structure of this essay, that they are the same problem, to be attacked with the same solutions. If so, and I’m not simply misunderstanding you, I don’t agree with that conclusion.
We can talk all day about the problems of separating data (content) from its usage context (application, presentation). As you note, this problem is as old as IT itself, and there are as many possible ways of solving it as there are clever minds in our industry. I’m rather fond of using Web standards, and microformats, myself, but YMWV.
But the wetware issue — the one that concerns itself with the behaviour of humans — is larger than, and orthogonal, to the data. Note I don’t say “independent” — that would be wrong. Data influences behaviour, no question. But they are not the same problem. If my observation about the #e2conf is correct, then it is a case in point.
(I led an Unconference session which I had subtitled “Death to the Silos!” The core of the discussion was my assertion that we are not well served by vendors (or anyone else) trying to sell us yet another wiki, or blog (to your point, above). Instead, we need collaborative capabilities baked directly into our business processes — what Ross Mayfield and his folk refer to as “in the flow”, and what I call “social processes”. I used the example of an insurance industry process (an automotive claim) to illustrate and frame the conversation. The audience was largely users / customers).
Judi: Thanks so much for sharing the context of your own specific challenge (I love collecting them — they’re so valuable), and for adding your own critical thought (I find I’m using the fish analogy a lot lately).
“the transaction costs of learning seem too large an investment of time and energy” — this is a tremendous clue that fits a pattern I’ve uncovered. These are ‘transformative capabilities’ that present a challenge: they have tremendous potential that can often be taken in many directions (Twitter has been ’shaped’ into many things different than originally intended), but they need some ‘context’ to ground them for the individual to relate. There are two phases/roles here — the first is often skipped: the adaptation of the tool and the adoption of the tool. Individuals should not be responsible for the overall business adaptation of the tool — although they certainly can move it forward, once adoption sets in.
ALL tools can be ’shaped’ to provide relevant context (even in the way they are introduced or interjected), as well, ‘guided immersion’ is often needed (look at all the many stories about how/when people ‘got’ Twitter — when they were at a conference and watched it in action, or someone walked them through scenarios). The transaction costs should NOT be borne by the individuals, over and over again — the multiplier effect of productivity loss is tremendous, but hidden. The tools must be shaped for ‘context’ (not the role of the delivered product — although I did suggest perhaps vendors might consider helping http://twurl.nl/y57hv3).
I say all this while recalling that these are not new issues. These are the same issues borne by anyone using a word processor or a spreadsheet for the first time. Training, simply teaches the individual how to shape themselves to the tool, thereby minimizing the potential of the tool — because they’ve spent so much time shaping themselves to the tool, they have no ‘costs’ left to invest in truly leveraging the tool to its fullest potential. Training itself imposes ‘proper use’, disincenting true understanding of the tool’s potential and experimenting with it’s edges.
The “seamlessness” you speak of is critical. It is the Rosetta Stone for the ‘adaptation’ that must be done to support adoption.
Thank YOU for reinforcing the key threads of thought I need to focus more on (I’m writing a related piece right now).
Mark: Classic to the ‘just try it’ mantra of this era, the UI for replying to comments makes it look as if they might get nested under the responses (e.g. interlaced rather than serial). Alas, that’s not the case.
In the end, we agree: “we need collaborative capabilities baked directly into our business processes.”
It is because of my belief in that fundamental premise that I wrote this piece (while the piece did not call it out specifically — it’s a theme of many of my posts for the past several years). You just said it a lot better than I’ve likely done before.
But there is also a challenge — it is one we’ve faced many times before when adopting ‘transformative technologies’, and we’ve failed. We too literally look at the existing and try to reshape it from where it stands, or worse, try to replace it. The issues I raised, focusing on the data/content, are critical to being able to address this opportunity from a variety of angles: ‘at’ the existing processes, or tangential to them — allowing the old and new to meet somewhere in the middle — where the ideal solution likely lies, both morphing into an ideal 3rd-form.
» Subscribe to the RSS feed for these comments
HTML-Tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Additional comments powered by BackType
