Archive for May 2006

The End of Empire: IBM, OpenDocument, and Enterprise Monocultures

May 30th, 2006 — 12:57am

IBM recently announced the next ver­sion of Lotus Notes will sup­port Open­Doc­u­ment For­mat as a native file for­mat (as reported in IBM Bets Big On Open Source In Next Release Of Lotus Notes). This shift to an open file for­mat is — as the major­ity of the cov­er­age of IBM’s announce­ment cor­rectly inter­prets it to be — a direct chal­lenge to the dom­i­nance of the Office suite of pro­duc­tiv­ity appli­ca­tions, a class of prod­ucts in which Microsoft has long relied on pro­pri­etary file for­mats as a cor­ner­stone of it’s mar­ket con­trol strat­egy. Mak­ing the chal­lenge explicit, the next ver­sion of Lotus Notes will also include “…built-in word pro­cess­ing, spread­sheet, and pre­sen­ta­tion graph­ics soft­ware”.
Since Microsoft relies on the inte­gra­tion of Share­Point and the Office suite as a pil­lar of it’s col­lab­o­ra­tion plans (in Gates out­lines Share­Point strat­egy, ham­mers IBM, John Fontana of Net­work World quotes Bill Gates as say­ing, “The key point is that Share­Point is becom­ing the key plat­form for col­lab­o­ra­tion of all types… When peo­ple look back on what we are doing with Office [2007] here, the most rev­o­lu­tion­ary ele­ment will be what we are doing with Share­Point.”), IBM’s shift to Open­Doc­u­ment For­mat is also a strate­gic move in the larger cat­e­gory of enter­prise col­lab­o­ra­tion, itself a sub­set of the emerg­ing com­pre­hen­sive infor­ma­tion work­ing envi­ron­ments For­rester Research calls the infor­ma­tion work­place.
An End to Impe­ri­al­ism
I’ve sug­gested already that the con­cep­tual con­struct labeled ‘col­lab­o­ra­tion’ is at heart another instance of enter­prise soft­ware and solu­tion ven­dor mar­ket­ing rhetoric designed to mask real­ity — it’s sim­ply not pos­si­ble to change estab­lished cul­tural, orga­ni­za­tional, per­cep­tual, or philo­soph­i­cal under­stand­ings of what work is and how it should be done with an approach cen­tered on tech­nol­ogy — in a quasi-utopian haze.
IBM’s adop­tion of Open­Doc­u­ment doesn’t change this pic­ture of the col­lab­o­ra­tion land­scape. Instead, it indi­cates a larger shift; dawn­ing recog­ni­tion and acknowl­edg­ment that mono­cul­tures are no longer viable, or valid, or broadly accept­able in the enter­prise arena.
The cre­ation and preser­va­tion of mono­cul­tures (recently in the news asso­ci­ated with Microsoft thanks to Dan Greer and oth­ers’ pre­science) is one of the salient char­ac­ter­is­tics of the old approach to enter­prise soft­ware solu­tions. It is espe­cially vis­i­ble in those enter­prise solu­tions whose intended role within a port­fo­lio of prod­uct and ser­vice offer­ings is to serve as a con­sis­tent rev­enue source, strate­gic bul­wark against com­pe­ti­tion, and cost shift­ing mech­a­nism whereby clients paid for the devel­op­ment of new prod­ucts and ser­vices, often under the guise of main­te­nance, patches, upgrades, etc.
Broadly, the old approach to enter­prise solu­tions was an impe­r­ial model, with aspects of colo­nial­ism, that pur­sued a mil­i­tary style take and hold growth pat­tern.
Wikipedia offers the fol­low­ing intro­duc­tion to impe­ri­al­ism:
“Impe­ri­al­ism is a pol­icy of extend­ing con­trol or author­ity over for­eign enti­ties as a means of acqui­si­tion and/or main­te­nance of empires. This is either through direct ter­ri­to­r­ial con­quest or set­tle­ment, or through indi­rect meth­ods of exert­ing con­trol on the pol­i­tics and/or econ­omy of other coun­tries. The term is often used to describe the pol­icy of a country’s dom­i­nance over dis­tant lands, regard­less of whether the coun­try con­sid­ers itself part of the empire.“
In the realm of soft­ware impe­ri­al­ism, the cus­tomer orga­ni­za­tion buy­ing and installing an enter­prise soft­ware pack­age was seen as a form of ter­ri­tory to be occu­pied or con­trolled by one or more hos­tile, rival­rous soft­ware and ser­vices ven­dors seek­ing to extract con­tin­u­ing rev­enues from their occu­pied pos­ses­sions; rev­enues in the form of main­te­nance, sup­port, cus­tomiza­tion, admin­is­tra­tion, or other sorts of solu­tion upkeep and exten­sion expenses.
Empires exerted con­trol for­mally through a vari­ety of polit­i­cal and eco­nomic mech­a­nisms, and infor­mally through influ­ence over polit­i­cal, eco­nomic and cul­tural spheres. Wikipedia’s entry for “empire” offers some instruc­tive par­al­lels to the enter­prise solu­tion model:
“First, in an empire there must be a Core and a Periph­ery. The empire’s struc­ture relates the core élite to the periph­eral élite in a mutu­ally ben­e­fi­cial fash­ion. Such as rela­tion­ship can be estab­lished through any num­ber of means, be they aggres­sive, coer­cise, or con­sen­sual. And while there is a ver­ti­cal rela­tion­ship between the core and periph­ery, there is a lack of sub­stan­tive rela­tions between periph­ery and periph­ery. This rela­tion­ship he describes as an incom­plete wheel: there are hubs and spokes, but no rim.“
The rela­tion­ship of inter­con­nected elites is easy to see in the pat­tern of incented sales and buy­ing deci­sions; “Need tick­ets to that exclu­sive event? No prob­lem, we’ll get them for you right away…“
But it’s the idea of dis­con­nected hubs and spokes that is key to under­stand­ing the cor­re­spon­dence between the old enter­prise model and impe­ri­al­ism. How often do indi­vid­ual client solu­tions (per­haps for dif­fer­ent depart­ments or busi­ness units) inter­act with each other? How often do instances of the same solu­tion for dif­fer­ent clients allow effec­tive inter­ac­tion between dif­fer­ent clients of the same ven­dor? How often do dif­fer­ent prod­ucts nom­i­nally part of ‘inte­grated’ solu­tion sets that were in actu­al­ity assem­bled by aggre­gat­ing the offer­ings of acquired com­pa­nies suc­cess­fully inter­act?
Again, with­out over­load­ing the anal­ogy, there are clear par­al­lels between the degrees of empire and the life­cy­cle of enter­prise solu­tions and ven­dors.
“Motyl also posits vary­ing degrees of empire: For­mal, Infor­mal, and Hege­monic. In a for­mal impe­r­ial rela­tion­ship, the core can appoint and dis­miss periph­eral elites, obvi­ate any exter­nal agenda or poli­cies, and directly con­trol the inter­nal agenda and poli­cies.“
As a con­sul­tant, I’ve seen aggres­sive soft­ware and ser­vices ven­dors directly drive busi­ness direc­tion, strat­egy, invest­ment, and process change deci­sions all too often. Orga­ni­za­tions lack­ing vision, effec­tive lead­er­ship, or those enter­ing com­pla­cency or suf­fer­ing decline look to ven­dors for lead­er­ship by proxy, allow­ing or ask­ing ven­dors to apply their own inap­pro­pri­ate frames of ref­er­ence and per­spec­tives to under­stand and choose courses of action in sit­u­a­tions out­side the vendor’s proper domain.
“In an infor­mal impe­r­ial rela­tion­ship, the core has influ­ence but not con­trol over appoint­ing and dis­miss­ing periph­eral elites, direct con­trol over the exter­nal agenda and poli­cies, and influ­ence over the inter­nal agenda and poli­cies.“
This infor­mal rela­tion­ship is the posi­tion of the entrenched ven­dor that pro­vides ‘per­spec­tive’ on many sit­u­a­tions out­side their proper domain. Ven­dors seek­ing to increase their ter­ri­tory within client orga­ni­za­tions often pur­sue growth via this method. Alter­na­tively, ven­dors will con­trol the envi­ron­ment in which cus­tomers and other ser­vice providers make deci­sions, as in the “open API” approach wherein the enter­prise exposes a por­tion of it’s archi­tec­ture, code base, or other plat­form, but main­tains exclu­sive con­trol over the API with­out any bind­ing com­mit­ments.
Wikipedia con­tin­ues:
“Finally, in a hege­monic rela­tion­ship, the core has no con­trol over appoint­ing or dis­miss­ing periph­eral elites, con­trol over the exter­nal agenda, influ­ence over exter­nal poli­cies, and no con­trol over the inter­nal agenda or poli­cies.“
This is the stage that the exist­ing col­lab­o­ra­tion solu­tions seem to be enter­ing, as wit­nessed by IBM’s announce­ment, and Microsoft’s fail­ure to date to advance the OpenXML stan­dard to full legit­i­macy.
The Pass­ing of Imperium
In essence, the old enter­prise approach exem­pli­fied the closed sys­tem, one that was sus­tained by the author­ity and cred­i­bil­ity of the orig­i­nat­ing ven­dor in the face of other com­pet­ing closed sys­tems. Fun­da­men­tally, soft­ware empires and impe­ri­al­ism are pred­i­cated on the valid­ity of closed sys­tems. What hap­pens when open sys­tems become the pre­ferred model?
“Empire ends when sig­nif­i­cant periph­eral inter­ac­tion begins, not nec­es­sar­ily when the core ceases its dom­i­na­tion of the periph­eries. The core-periphery rela­tion­ship can be as strong or weak as pos­si­ble and remain an empire as long as there is only insignif­i­cant inter­ac­tion between periph­ery and periph­ery.“
Open­Doc­u­ment is designed to allow exactly the sort of periph­ery to periph­ery inter­ac­tion that closed archi­tec­tures pro­hib­ited. IBM’s shift to Open­Doc­u­ment shows aware­ness that old style closed impe­r­ial enter­prise sys­tems are no longer viable. In this, they are fol­low­ing the chang­ing rhetoric of those such as Larry Can­nell from, who offers a strongly pro-open sys­tem view in A Vision For Col­lab­o­ra­tive Tech­nolo­gies:
“I believe open­ness breeds inno­va­tion, and there are many parts of the col­lab­o­ra­tive tech­nol­ogy mar­ket that need a big injec­tion of inno­va­tion. While ven­dors con­tinue push­ing inte­gra­tion as their pri­mary value propo­si­tion for closed sys­tems, the astute com­peti­tor will embrace open­ness and pro­vide inno­va­tion within an ecosys­tem of col­lab­o­ra­tive tech­nolo­gies based on open stan­dards. Today we have a plethora of email sys­tems which nearly every­one con­nected to the Inter­net is capa­ble of using. We need com­pa­ra­ble open and sim­ple choices for other col­lab­o­ra­tive tech­nolo­gies; whether it is col­lab­o­ra­tive work­spaces or online com­mu­ni­ties. It will not be until we have sim­ple open stan­dards that fos­ter famil­iar­ity and easy inter­con­nec­tiv­ity that will we see wide­spread use and explo­sive inno­va­tion.“
Can­nell is care­ful here to take a pos­i­tive and forward-looking line regard­ing col­lab­o­ra­tion, but his view of closed sys­tems is clearly neg­a­tive. And the implied con­se­quence of a closed sys­tem is lack of inno­va­tion, one of the key signs of orga­ni­za­tions in decline.
Didn’t I start out by say­ing that we should be wary of the mar­ket­ing rhetoric sur­round­ing col­lab­o­ra­tion? Yes, pre­cisely because the major­ity of the rhetoric com­ing from enter­prise ven­dors still exem­pli­fies the closed sys­tem, impe­ri­al­ist enter­prise ethos.
How­ever, in the case of IBM, it’s clear that they’ve antic­i­pated the con­se­quences of ignor­ing the envi­ron­men­tal shift to open sys­tems that is at hand, and reacted accord­ingly, at least as regards the core doc­u­ment stan­dard under­ly­ing Lotus Notes (which is still awful, BTW, just in case any­one mis­in­ter­prets this arti­cle to mean I think oth­er­wise…). The rela­tion­ship of Notes to Work­place seems largely unknown at this point, and still sub­ject to bit­ter infight­ing, in another great par­al­lel to the impe­r­ial model. Microsoft, as the other major col­lab­o­ra­tion ven­dor, may be able to stem the tide against open sys­tems in the short term, but will even­tu­ally have to respond.
My thoughts on the cur­rent form of enter­prise solu­tions as a class / indus­try / way of solv­ing busi­ness prob­lems remain unal­tered — in fact I think that IBM’s move sup­ports many of the pre­dic­tions I made ear­lier this year, fol­low­ing ear­lier treat­ments by oth­ers writ­ing on the same subjects.

1 comment » | Ideas

Cartograms, Tag Clouds and Visualization

May 22nd, 2006 — 10:56pm

I was enjoy­ing some of the engag­ing car­tograms avail­able from Worldmap­per, when I real­ized tag clouds might have some strong par­al­lels with car­tograms. After a quick sub­sti­tu­tion exer­cise, I’ve come to believe tag clouds could be to lists of meta­data what car­tograms are to maps; attempted solu­tions to sim­i­lar visu­al­iza­tion prob­lems dri­ven by com­mon and his­tor­i­cally con­sis­tent infor­ma­tion needs.
Here’s the train of thought behind the anal­ogy. Car­tograms are the dis­torted but cap­ti­vat­ing maps that change the famil­iar shapes of places on a map to visu­ally show data about geo­graphic loca­tions. Car­tograms change the way loca­tions appear to make a point or com­mu­ni­cate rel­a­tive dif­fer­ences in the under­ly­ing data; for exam­ple, by mak­ing coun­tries with higher GDP (gross domes­tic prod­uct) big­ger, and those with lower GDP smaller. In the exam­ple below, Japan’s size is much larger than it’s geo­graphic area, because it’s GDP is so high (it’s the dark green blob on the far right, much larger than China or India), while Africa is nearly invis­i­ble.
Gross Domes­tic Prod­uct

Tag clouds pur­sue the same goal: to enhance our under­stand­ing by com­mu­ni­cat­ing con­tex­tual mean­ing through changes in the way a set of things are visu­al­ized, rely­ing addi­tional dimen­sions of infor­ma­tion to make con­text explicit. Where car­tograms change geo­graphic units, tag clouds change the dis­play of a list of labels (the end point of a chain of link­ages con­nect­ing con­cepts to focuses) to com­mu­ni­cate the seman­tic impor­tance or con­text of the under­ly­ing con­cepts shown in the list.
Visu­ally, the rela­tion­ship of clouds to lists is sim­i­lar to that of maps and car­tograms; com­pare these two ren­der­ings of the most pop­u­lar search terms recorded by, one a sim­ple list and the other a tag cloud.
List Ren­der­ing of Search Terms

Cloud Ren­der­ing of Search Terms

This expla­na­tion of car­tograms from Car­togram Cen­tral a site sup­ported by the U.S. Geo­log­i­cal Sur­vey and tional Cen­ter for Geo­graphic Infor­ma­tion and Analy­sis makes the par­al­lels clearer, in greater detail.
“A car­togram is a type of graphic that depicts attrib­utes of geo­graphic objects as the object’s area. Because a car­togram does not depict geo­graphic space, but rather changes the size of objects depend­ing on a cer­tain attribute, a car­togram is not a true map. Car­tograms vary on their degree in which geo­graphic space is changed; some appear very sim­i­lar to a map, how­ever some look noth­ing like a map at all.“
Now for the cut and paste. Sub­sti­tute ‘tag cloud’ for car­togram, ‘seman­tic’ for geo­graphic, and ‘list’ in for map, and the same expla­na­tion reads:
“A tag cloud is a type of graphic that depicts attrib­utes of seman­tic objects as the object’s area. Because a tag cloud does not depict seman­tic space, but rather changes the size of objects depend­ing on a cer­tain attribute, a tag cloud is not a true list. Tag Clouds vary on their degree in which seman­tic space is changed; some appear very sim­i­lar to a list, how­ever some look noth­ing like a list at all.“
This is a good match for the cur­rent under­stand­ing of tag clouds.
Div­ing in deeper, Car­togram Cen­tral offers an excerpt from Car­tog­ra­phy: The­matic Map Design, that goes into more detail about the spe­cific char­ac­ter­is­tics of car­tograms.
Erwin Raisz called car­tograms ‘dia­gram­matic maps.’ Today they might be called car­tograms, value-by-area maps, anamor­phated images or sim­ply spa­tial trans­for­ma­tions. What­ever their name, car­tograms are unique rep­re­sen­ta­tions of geo­graph­i­cal space. Exam­ined more closely, the value-by-area map­ping tech­nique encodes the mapped data in a sim­ple and effi­cient man­ner with no data gen­er­al­iza­tion or loss of detail. Two forms, con­tigu­ous and non-contiguous, have become pop­u­lar. Map­ping require­ments include the preser­va­tion of shape, ori­en­ta­tion con­ti­gu­ity, and data that have suit­able vari­a­tion. Suc­cess­ful com­mu­ni­ca­tion depends on how well the map reader rec­og­nizes the shapes of the inter­nal enu­mer­a­tion units, the accu­racy of esti­mat­ing these areas, and effec­tive leg­end design. Com­plex forms include the two-variable map. Car­togram con­struc­tion may be by man­ual or com­puter means. In either method, a care­ful exam­i­na­tion of the logic behind the use of the car­togram must first be under­taken.“
Doing the same sub­sti­tu­tion exer­cise on this excerpt with the addi­tion of ‘rel­e­vance’ for value, ‘size’ for area, and ‘term’ for shape, yields sim­i­lar results:
“Erwin Raisz called tag clouds ‘dia­gram­matic lists.’ Today they might be called tag clouds, relevance-by-size lists, anamor­phated images or sim­ply spa­tial trans­for­ma­tions. What­ever their name, tag clouds are unique rep­re­sen­ta­tions of seman­tic space. Exam­ined more closely, the relevance-by-size list­ing tech­nique encodes the listed data in a sim­ple and effi­cient man­ner with no data gen­er­al­iza­tion or loss of detail. Two forms, con­tigu­ous and non-contiguous, have become pop­u­lar. List­ing require­ments include the preser­va­tion of term, ori­en­ta­tion, con­ti­gu­ity, and data that have suit­able vari­a­tion. Suc­cess­ful com­mu­ni­ca­tion depends on how well the list reader rec­og­nizes the terms (of the inter­nal enu­mer­a­tion units), the accu­racy of esti­mat­ing these sizes, and effec­tive leg­end design. Com­plex forms include the two-variable list. Tag cloud con­struc­tion may be by man­ual or com­puter means. In either method, a care­ful exam­i­na­tion of the logic behind the use of the tag cloud must first be under­taken.“
The cor­re­spon­dence here is strong as well.
Sta­ble Need
The fact that car­tograms and tag clouds show close par­al­lels means that while the tag cloud may be a new user inter­face ele­ment emerg­ing for the Web (and major desk­top appli­ca­tions like Out­look, in the case of Tagloc­ity), tag clouds as a type of visu­al­iza­tion have strong prece­dents in other much more mature user expe­ri­ence con­texts, such as the dis­play of mul­ti­ple dimen­sions of infor­ma­tion within geo­graphic or geospa­tial frames of ref­er­ence. Instances of strong cor­re­spon­dence of prob­lem solv­ing approach in both mature and emerg­ing con­texts could indi­cate sim­ple appli­ca­tion of par­al­lel fram­ing (from the mature con­text to the emerg­ing con­text) as an untested con­di­tional, until the true extent of diver­gence sep­a­rat­ing the two con­texts is under­stood. This is very com­mon new media.
Instead, in the case of tag clouds, I think it points at sta­ble needs dri­ving struc­turally sim­i­lar solu­tions to the basic prob­lem of how to visu­ally com­mu­ni­cate impor­tant rela­tion­ships and addi­tional dimen­sions of mean­ing under the lim­i­ta­tions of inher­ent flat­ness. The par­al­lels between car­tograms and tag clouds place the appear­ance of the tag cloud within the larger his­tory of con­tin­u­ing explo­ration of new ways of visu­al­iz­ing infor­ma­tion. In this view, tag clouds are a recent man­i­fes­ta­tion of the sta­ble need to cre­ate strong and effec­tive visual ways of con­vey­ing more than mem­ber­ship in a one-dimensional set (the list), or loca­tion and extent within a two-dimensional coör­di­nate sys­tem (the map).

1 comment » | Ideas, Tag Clouds

Who Should Own How We Work? Collaboration, the New Enterprise Application

May 14th, 2006 — 11:55pm

Col­lab­o­ra­tion is the lat­est ral­ly­ing cry of soft­ware ven­dors hop­ing to embed new gen­er­a­tions of enter­prise class tools and user expe­ri­ences into the fab­ric of the mod­ern work­place. Microsoft, IBM, and other firms expect that con­trol or lead­er­ship in the mar­ket for col­lab­o­ra­tion, whether by own­ing the archi­tec­ture, sys­tems, or other solu­tion com­po­nents, will be lucra­tive. A recent Rad­i­cati Group study (qual­ity uncon­firmed…) of the mar­ket size for enter­prise col­lab­o­ra­tion offered an esti­mate of $1.6 bil­lion now, grow­ing 10% annu­ally to $2.3 bil­lion in 2010.
Beyond the sub­stan­tial money to be made cre­at­ing, sell­ing, installing, and ser­vic­ing col­lab­o­ra­tion solu­tions lies the strate­gic advan­tage of mar­ket def­i­n­i­tion. The vendor(s) that own(s) the col­lab­o­ra­tion space expect(s) to become an inte­gral to the knowl­edge economy’s sup­port­ing envi­ron­ment in the same way that Ford and Gen­eral Motors became essen­tial to the sub­ur­ban­ized con­sumer archi­tec­tures of the post WWII era by serv­ing simul­ta­ne­ously as employ­ers, man­u­fac­tur­ers, cul­tural mar­keters, cap­i­tal reser­voirs, and auto­mo­bile sell­ers. Col­lab­o­ra­tion ven­dors know that achiev­ing any level of indis­pen­si­bil­ity will enhance their longevity by mak­ing them a neces­sity within the knowl­edge econ­omy.
It’s worth tak­ing a moment to call atten­tion to the impli­ca­tions: by defin­ing the user expe­ri­ences and tech­no­log­i­cal build­ing blocks brought together to real­ize col­lab­o­ra­tion in large enter­prises, these ven­dors will directly shape our basic con­cepts and under­stand­ing (our men­tal mod­els and cog­ni­tive frames) of col­lab­o­ra­tion. Once embed­ded, these archi­tec­tures, sys­tems, and busi­ness processes, and the social struc­tures and con­cep­tual mod­els cre­ated in response, will in large part define the (infor­ma­tion) work­ing envi­ron­ments of the future.
And yes, this is exactly what these ven­dors aspire to achieve; the Microsoft Share­point Prod­ucts and Tech­nolo­gies Devel­op­ment Team blog, offers:
“Share­Point Prod­ucts and Tech­nolo­gies have become a key part of our strat­egy for deliv­er­ing a com­plete work­ing envi­ron­ment for infor­ma­tion work­ers, where they can col­lab­o­rate together, share infor­ma­tion with oth­ers, and find infor­ma­tion and peo­ple that can help them solve their busi­ness prob­lems.“
And IBM’s mar­ket­ing is not pitched and deliv­ered in a man­ner as sweep­ing, but the impli­ca­tions are sim­i­lar, as in the overview IBM® Work­place™: Sim­ply a bet­ter way]:
IBM Work­place™ Solu­tions are role-based frame­works to help cus­tomers apply IBM Work­place tech­nolo­gies faster and more pro­duc­tively… These solu­tions are designed to pro­vide ‘short-cuts’ for cre­at­ing a high per­for­mance role-based work envi­ron­ment, help­ing to accel­er­ate time-to-value.“
The Mod­els for com­mu­ni­ca­tion and rela­tion­ships built into our tools are very pow­er­ful, and often employed in other spheres of life. How many times have you started writ­ing a birth­day card for a friend, and found your­self instinc­tively com­pos­ing a set of bul­let points list­ing this person’s chief virtues, notable char­ac­ter traits, and the most impor­tant / amus­ing moments of your friend­ship. The creep­ing ubiq­uity of the rhetor­i­cal style of Pow­er­point (Tufte’s essay here) is just one exam­ple of the tremen­dous social impact of a habit­u­ated model of com­mu­nica­tive prac­tices that’s run amok.
What does the future hold, in terms of enter­prise ven­dor con­trol over every­day work­ing expe­ri­ences? I’ve writ­ten before on the idea that the days of the mono­lithic enter­prise sys­tems are num­bered, mak­ing the point along the way that these behe­moths are the result of a top-down, one-size-for-all approach. I think the same is true of the cur­rent approach to col­lab­o­ra­tion solu­tions and work­ing envi­ron­ments. And so I was happy to see Andrew McAfee of Har­vard Busi­ness School make sev­eral strong points about how enter­prise col­lab­o­ra­tion efforts will real­ize greater suc­cess by *reduc­ing* the amount of struc­ture imposed on their major ele­ments — roles, work­flows, arti­facts, and rela­tion­ships — in advance of actual use.
McAfee sees con­sid­er­able ben­e­fit in new approaches to enter­prise IT invest­ment and man­age­ment that reduce the top-down and imposed nature of enter­prise envi­ron­ments and solu­tions, in favor of emer­gent struc­tures cre­ated by the peo­ple who must work suc­cess­fully within them. McAfee advo­cates allow­ing staff to cre­ate the iden­ti­ties, struc­tures and pat­terns that will orga­nize and gov­ern their col­lab­o­ra­tion envi­ron­ments as nec­es­sary, in an emer­gent fash­ion, instead of fix­ing these aspects long before users begin to col­lab­o­rate.
McAfee says:
“When I look at a lot of cor­po­rate col­lab­o­ra­tion tech­nolo­gies after spend­ing time at Wikipedia,, Flickr, and Blog­ger I am struck by how reg­i­mented, inflex­i­ble, and lim­ited the cor­po­rate stuff seems, because it does some or all of the following:

  • Gives users iden­ti­ties before they start using the tech­nol­ogy. These iden­ti­ties assign them cer­tain roles, priv­i­leges, and access rights, and exclude them from oth­ers. These iden­ti­ties almost always also place them within the exist­ing orga­ni­za­tional struc­ture and for­mal cor­po­rate hierarchy.
  • Con­tains few truly blank pages. Instead, it has lots of templates–for meet­ings, for project track­ing, for doc­u­ments and reports, etc.
  • Has tons of explicit or implicit work­flow– seqences [sic] of tasks that must be exe­cuted in order.

How much of this struc­ture is nec­es­sary? How much is valu­able? Well, the clear suc­cess sto­ries of Web 2.0 demon­strate that for at least some types of com­mu­nity and col­lab­o­ra­tion, none of it is.“
The crit­i­cal ques­tion is then “what types of com­mu­nity and col­lab­o­ra­tion require which approaches to cre­at­ing struc­ture, and when?” As any­one who’s used a poorly or overly struc­tured col­lab­o­ra­tion (or other enter­prise) tool knows, the result­ing envi­ron­ment is often anal­o­gous to a feu­dal soci­ety designed and man­aged by crypto-technical over­lords; one in which most users feel as if they are serfs bound to the land for in per­pe­tu­ity in order to sup­port the leisure-time and war-making indul­gences of a small class of share­hold­ing nobil­ity.
Answer­ing these ques­tions with con­fi­dence based on expe­ri­ence will likely take time in the range of years, and require numer­ous failed exper­i­ments. There’s a larger con­text to take into account: the strug­gle of enter­prise soft­ware ven­dors to extend their reach and longevity by dom­i­nat­ing the lan­guage of col­lab­o­ra­tion and the range of offer­ings is one part of a much broader effort by soci­ety to under­stand dra­matic shifts in our ways of work­ing, and the social struc­tures that are both dri­ven by and shape these new ways of work­ing. And so there are sev­eral impor­tant ideas and ques­tions under­ly­ing McAfee’s assess­ment that social sys­tem design­ers should under­stand.
One of the most impor­tant is that the notion of “col­lab­o­ra­tion” is con­cep­tual short­hand for how you work, who you work with, and what you do. In other words, it’s a dis­til­la­tion of your pro­fes­sional iden­tity. Your role in a col­lab­o­ra­tion envi­ron­ment defines who you are within that envi­ron­ment.
More impor­tantly, from the per­spec­tive of growth and devel­op­ment, your sys­tem assigned role deter­mines who you can *become*. Knowl­edge work­ers are val­ued for their skills, expe­ri­ence, pro­fes­sional net­works, pub­lic rep­u­ta­tions, and many other fluid, con­text depen­dent attrib­utes. And so lock­ing down their iden­ti­ties in advance strips them of a sub­stan­tial pro­por­tion of their cur­rent value, and simul­ta­ne­ously reduces their abil­ity to adapt, inno­vate, and respond to envi­ron­men­tal changes by shift­ing their think­ing or prac­tices. In plain terms, deter­min­ing their iden­ti­ties in advance pre­cludes the cre­ation of future value.
Another impor­tant under­ly­ing idea is the impor­tance of prop­erly under­stand­ing the value and util­ity of dif­fer­ing approaches to sys­tem­ati­za­tion in dif­fer­ing con­texts. McAfee’s assess­ment of the unhealthy con­se­quences of impos­ing too much struc­ture in advance is use­ful for social sys­tem design­ers (such as infor­ma­tion archi­tects and knowl­edge man­agers), because it makes the out­comes of implicit design strate­gies and assump­tions clear and tan­gi­ble, in terms of the neg­a­tive effects on the even­tual users of the col­lab­o­ra­tion envi­ron­ment. For com­plex and evolv­ing group set­tings like the mod­ern enter­prise, cre­at­ing too much struc­ture in advance points to a mis­placed under­stand­ing of the value and role of design and archi­tec­ture.
Fun­da­men­tally, it indi­cates an over­es­ti­ma­tion of the value of the activ­ity of sys­tem­atiz­ing (design­ing) col­lab­o­ra­tion envi­ron­ments to high lev­els of detail, and with­out recog­ni­tion for evo­lu­tion­ary dynam­ics. The design or struc­ture of any col­lab­o­ra­tion envi­ron­ment — of any social sys­tem — is only valu­able for how well it encour­ages rela­tion­ships and activ­ity which advance the goals of the orga­ni­za­tion and it’s mem­bers. The value of a designer in the effort to cre­ate a col­lab­o­ra­tive com­mu­nity lies in the abil­ity to cre­ate designs that lead to effec­tive col­lab­o­ra­tion, not in the num­ber or speci­ficity of the designs they pro­duce, and espe­cially not in the arti­facts cre­ated dur­ing design — the tem­plates, work­flows, roles, and other McAfee men­tioned above. To sim­plify the dif­fer­ent views of what’s appro­pri­ate into two arti­fi­cially seg­mented camps, the [older] view that results in the pre­ma­ture cre­ation of too much struc­ture val­i­dates the design of things / arti­facts / sta­tic assem­blies, whereas the newer view valu­ing min­i­mal and emer­gent struc­tures acknowl­edges the greater effi­cacy of design­ing dynamic sys­tems / flows / frame­works.
The overly spe­cific and rigid design of many col­lab­o­ra­tion sys­tem com­po­nents com­ing from the older design view­point in fact says much about how large, com­plex enter­prises choose to inter­pret their own char­ac­ters, and cre­ate tools accord­ingly. Too often, a desire to achieve total­ity lies at the heart of this approach.
Of course, most total­i­ties only make sense — exhibit coher­ence — when viewed from within, and when using the lan­guage and con­cepts of the total­ity itself. The result is that attempts to achieve total­ity of design for many com­plex con­texts (like col­lab­o­ra­tion within enter­prises large or small) rep­re­sent a self-defeating approach. That the approach is self-defeating is gen­er­ally ignored, because the pur­suit of total­ity is a self-serving exer­cise in power val­i­da­tion, that ben­e­fits power hold­ers by con­sum­ing resources poten­tially used for other pur­poses, for exam­ple, to under­mine their power.
With the chimera of total­ity set in proper con­text, it’s pos­si­ble to see how col­lab­o­ra­tion envi­ron­ments — at least in their most poorly con­ceived man­i­fes­ta­tions — will resem­ble vir­tual retreads of Tay­lorism, wherein the real accom­plish­ment is to jus­tify the effort and expense involved in cre­at­ing the sys­tem by point­ing at an exces­sive quan­tity of pre­de­ter­mined struc­ture await­ing habi­ta­tion and use by dis­en­fran­chised staff.
At present, I see two diver­gent and com­pet­ing trends in the realm of enter­prise solu­tions and user expe­ri­ences. The first trend is toward homo­gene­ity of the work­ing envi­ron­ment with large amounts of struc­ture imposed in advance, exem­pli­fied by com­pre­hen­sive col­lab­o­ra­tion suites and archi­tec­tures such as MSOf­fice / Share­point, or IBM’s Work­place.
The sec­ond trend is toward het­ero­gene­ity in the struc­tures inform­ing the work­ing envi­ron­ment, vis­i­ble as vari­able pat­terns and locuses of col­lab­o­ra­tion estab­lished by fluid groups that rely on adhoc assort­ment of tools from dif­fer­ent sources (Base­Camp, GMail, social book­mark­ing ser­vices, RSS syn­di­ca­tion of social media struc­tures, com­mu­ni­ties of prac­tice, busi­ness ser­vices from ASP providers, open source appli­ca­tions, etc.).
But this itself is a short term view, when sit­u­a­tion within a longer term con­text is nec­es­sary. It is com­mon for sys­tems or envi­ron­ments of all sizes and com­plex­i­ties to oscil­late cycli­cally from greater to lesser degrees of struc­ture, along a con­tin­uüm rang­ing from homo­ge­neous to het­ero­ge­neous. In the short term view then, the quest for total­ity equates to homo­gene­ity, or even efforts at dom­i­na­tion. In the long term view, how­ever, the quest for total­ity could indi­cate an imma­ture ecosys­tem that is not diverse, but may become so in time.
Apply­ing two (poten­tial) lessons from ecol­ogy — the value of diver­sity as an enhancer of over­all resilience in sys­tems, and the ten­dency of mono­cul­tures to exhibit high fragility — to McAfee’s points on emer­gence, as well as the con­tin­uüm view of shift­ing degress of homo­gene­ity, should tell us that col­lab­o­ra­tion solu­tion design­ers would be wise to do three things:

  1. Adopt the new design view­point and focus on design­ing struc­tures that allow col­lab­o­ra­tors to cre­ate value
  2. Spec­ify as lit­tle struc­ture of any kind in advance as possible
  3. Antic­i­pate the emer­gence of new archi­tec­tural ele­ments, and allow for their incor­po­ra­tion under the guid­ance of the com­mu­nity of collaborators

The end result should be an enter­prise approach to col­lab­o­ra­tion that empha­sizes the design of infra­struc­ture for com­mu­ni­ties that cre­ate their own struc­tures. Big ven­dors be wary of this enlight­ened point of view, unless you’re will­ing to respond in kind.

4 comments » | Ideas

Tag Clouds: "A New User Interface?"

May 3rd, 2006 — 10:58pm

In Piv­ot­ing on tags to cre­ate bet­ter nav­i­ga­tion UI Matt McAl­lis­ter offers the idea that we’re see­ing “a new user inter­face evolv­ing out of tag data,” and uses Wikio as an exam­ple. For con­text, he places tag clouds within a con­tin­uüm of the evo­lu­tion of web nav­i­ga­tion, from list views to the new tag-based nav­i­ga­tion emerg­ing now.
It’s an insight­ful post, and it allows me to build on strong ground­work to talk more about why and how tag clouds dif­fer from ear­lier forms of nav­i­ga­tion, and will become [part of] a new user inter­face.
Matt iden­ti­fies five ‘leaps’ in web nav­i­ga­tion inter­faces that I’ll summarize:

  1. List view; a list of links
  2. Left-hand col­umn; a stan­dard loca­tion for lists of links used to navigate
  3. Search boxes and results pages; mak­ing very large lists manageable
  4. Tab nav­i­ga­tion; a list of other nav­i­ga­tion lists
  5. Tag nav­i­ga­tion; tag clouds

A Les­son in ‘Lis­tory’
As Matt men­tions, all four pre­de­ces­sors to tag based nav­i­ga­tion are really vari­a­tions on the under­ly­ing form of the list. There’s use­ful his­tory in the evo­lu­tion of lists as web nav­i­ga­tion tools. Early lists used for nav­i­ga­tion were sta­tic, cho­sen by a site owner, ordered, and flat: recall the lists of favorite sites that appeared at the bot­tom of so many early per­sonal home pages.
These basic nav­i­ga­tion lists evolved a vari­ety of order­ing schemes, (alpha­bet­i­cal, numeric), began to incor­po­rate hier­ar­chy (shown as sub-menus in nav­i­ga­tion sys­tems, or as indent­ing in the left-column Matt men­tions), and allowed users to change their order­ing, for exam­ple by sort­ing on a vari­ety of fields or columns in search results.
From sta­tic lists whose con­tents do not change rapidly and reflect a sin­gle point of view, the lists employed for web nav­i­ga­tion and search results then became dynamic, per­son­al­ized, and reflec­tive of mul­ti­ple points of view. Ama­zon and other e-commerce des­ti­na­tions offered recently viewed items (yours or oth­ers), things most requested, sets bounded by date (pub­lished last year), sets dri­ven by vary­ing para­me­ters (related arti­cles), and lists deter­mined by the nav­i­ga­tion choices of oth­ers who fol­lowed sim­i­lar paths.)
But they remained fun­da­men­tally lists. They item­ized or enu­mer­ated choices of one kind or another, indi­cated implicit or explicit prece­dence through order­ing or the absence of order­ing, and were designed for lin­ear inter­ac­tion pat­terns: start at the begin­ning (or the end, if you pre­ferred an alter­na­tive per­spec­tive — I still habit­u­ally read mag­a­zines from back to front…) and work your way through.
Tag clouds are dif­fer­ent from lists, often by con­tents and pre­sen­ta­tion, and more impor­tantly by basic assump­tion about the kind of inter­ac­tion they encour­age. On tag-based nav­i­ga­tion Matt says, “This is a new layer that pre­empts the search box in a way. The visual rep­re­sen­ta­tion of it is a tag cloud, but the inter­ac­tion is more like a pivot.” Matt’s men­tion of the inter­ac­tion hits on an impor­tant aspect that’s key to under­stand­ing the dif­fer­ences between clouds and lists: clouds are not lin­ear, and are not designed for lin­ear con­sump­tion in the fash­ion of lists.
I’m not say­ing that no one will read clouds left to right (with Roman alpha­bets), or right to left if they’re in Hebrew, or in any other way. I’m say­ing that tag clouds are not meant for ‘read­ing’ in the same way that lists are. As they’re com­monly visu­al­ized today, clouds sup­port mul­ti­ple entry points using visual dif­fer­en­tia­tors such as color and size.
Start­ing in the mid­dle of a list and wan­der­ing around just increases the amount of visual and cog­ni­tive work involved, since you need to remem­ber where you started to com­plete your sur­vey. Start­ing in the “mid­dle” of a tag cloud — if there is such a loca­tion — with a brightly col­ored and big juicy visual morsel is *exactly* what you’re sup­posed to do. It could save you quite a lot of time and effort, if the cloud is well designed and prop­erly ren­dered.
Kunal Anand cre­ated a visu­al­iza­tion of the inter­sec­tions of his tags that shows the dif­fer­ences between a cloud and a list nicely. This is at heart a pic­ture, and accord­ingly you can start look­ing at it any­where / any­way you pre­fer.
Visu­al­iz­ing My Tags

We all know what a list looks like…
iTunes Play Lists

What’s In a Name?
Describ­ing a tag cloud as a weighted list (I did until I’d thought about it fur­ther) misses this impor­tant qual­i­ta­tive dif­fer­ence, and reflects our early stages of under­stand­ing of tag clouds. The term “weighted list” is a list-centered view of tag clouds that comes from the pre­ced­ing frame of ref­er­ence. It’s akin to describ­ing a com­puter as an “arith­metic engine”, or the print­ing press as “mov­able type”.
[Aside: The label for tag clouds will prob­a­bly change, as we develop con­cepts and lan­guage to frame new the user expe­ri­ences and infor­ma­tion envi­ron­ments that include clouds. For exam­ple, the lan­guage Matt uses — the word ‘pivot’ when he talks about the expe­ri­ence of nav­i­gat­ing via the tag cloud in Wikio, not the word ‘fol­low’ which is a default for describ­ing nav­i­ga­tion — in the post­ing and his screen­cast reflects a pos­si­ble shift in fram­ing.]
A Cam­era Obscura For the Seman­tic Land­scape
I’ve come to think of a tag cloud as some­thing like the image pro­duced by a cam­era obscura.
Cam­era Obscura
Where the cam­era obscura ren­ders a real-world land­scape, a tag cloud shows a seman­tic land­scape like those cre­ated by Amber Frid-Jimenez at MIT.
Seman­tic Land­scape

Seman­tic Land­scape

Like a cam­era obscura image, a tag cloud is a fil­tered visu­al­iza­tion of a mul­ti­di­men­sional world. Unlike a cam­era obscura image, a tag cloud allows move­ment within the land­scape. And unlike a list, tag clouds can and do show rela­tion­ships more com­plex than one-dimensional lin­ear­ity (expe­ri­enced as prece­dence). This abil­ity to show more than one dimen­sion allows clouds to reflect the struc­ture of the envi­ron­ment they visu­al­ize, as well as the con­tents of that envi­ron­ment. This frees tag clouds from the lim­i­ta­tion of sim­ply item­iz­ing or enu­mer­at­ing the con­tents of a set, which is the fun­da­men­tal achieve­ment of a list.
Ear­lier, I shared some obser­va­tions on the struc­tural evo­lu­tion — from sta­tic and flat to hier­ar­chi­cal and dynamic — of the lists used as web nav­i­ga­tion mech­a­nisms. As I’ve ven­tured else­where, we may see a sim­i­lar evo­lu­tion in tag clouds.
It is already clear that we’re wit­ness­ing evo­lu­tion in the pre­sen­ta­tion of tag clouds in step with their greater visu­al­izatin capa­bil­i­ties. Clouds now rely on an expand­ing vari­ety of visual cues to show an increas­ingly detailed view of the under­ly­ing seman­tic land­scape: prox­im­ity, depth, bright­ness, inten­sity, color of item, color of field around item. I expect clouds will develop other cues to help depict the many con­nec­tions (per­ma­nent or tem­po­rary) link­ing the labels in a tag cloud. It’s pos­si­ble that tag clouds will offer a user expe­ri­ence sim­i­lar to some of the ontol­ogy man­age­ment tools avail­able now.
Is this “a new user inter­face”? That depends on how you define new. In Shap­ing Things, author and futur­ist Bruce Ster­ling sug­gests, “the future com­posts the past” — mean­ing that new ele­ments are sub­sumed into the accu­mu­la­tion of lay­ers past and present. In the con­text of nav­i­ga­tion sys­tems and tag clouds, that implies that we’ll see mix­tures of lists from the four pre­vi­ous stages of nav­i­ga­tion inter­face, and clouds from the lat­est leap; a fusion of old and new.
Exam­ples of this com­post­ing abound, from to Wikio that Matt McAl­lis­ter exam­ined. Tag Clouds

Wikio Tag Cloud

As lists encour­aged lin­ear inter­ac­tions as a result of their struc­ture, it’s pos­si­ble that new user inter­faces rely­ing on tag clouds will encour­age dif­fer­ent kinds of seek­ing or find­ing behav­iors within infor­ma­tion expe­ri­ences. In “The endan­gered joy of serendip­ity” William McK­een bemoans the decrease of serendip­ity as a result of pre­cisely directed and tar­geted media, search­ing, and inter­ac­tions. Tag clouds — by offer­ing many con­nec­tions and mul­ti­ple entry paths simul­ta­ne­ously — may help reju­ve­nate serendip­ity in dan­ger in a world of closely focused lists.

2 comments » | Ideas, Tag Clouds

Back to top