tag:blogger.com,1999:blog-240091422024-03-13T23:31:20.514-07:00Doc Or DieProgrammers use the idiom of “doc or die” when a procedure needs a document and fails if it can’t find it. Documents are also essential in web services, supply chains, and information-intensive applications in every domain. This blog discusses documents and information designs “in the wild" - especially those that are exceptionally good or exceptionally bad.
Bob Glushko (along with Tim McGrath) is the author of DOCUMENT ENGINEERING (MIT Press 2005)Bob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.comBlogger84125tag:blogger.com,1999:blog-24009142.post-9131160088890676352008-10-29T02:42:00.000-07:002008-10-29T03:02:09.338-07:00A Vaccination for the Service Science Epidemic<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDfpFdfmWESDSDkfrtePrR3ZuTHV-Du73ls-iyxzzhfeW2fV554OxZGDX54Glo-AZdhjaJwa7n7XJcSTBG2u1rGVqv1y63V-9xcRg2DGx4NwWsV95cy5-u2JWbeAbOg1rRJTkQ/s1600-h/SSME-HefleyNormative.gif"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 400px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDfpFdfmWESDSDkfrtePrR3ZuTHV-Du73ls-iyxzzhfeW2fV554OxZGDX54Glo-AZdhjaJwa7n7XJcSTBG2u1rGVqv1y63V-9xcRg2DGx4NwWsV95cy5-u2JWbeAbOg1rRJTkQ/s400/SSME-HefleyNormative.gif" border="0" alt=""id="BLOGGER_PHOTO_ID_5262509938317260370" /></a><br />It is truly astounding to see how fast the idea of <a href="http://www.research.ibm.com/ssme/"> "service science"</a> (or "SSME" - for "Service Science, Management and Engineering") is spreading since IBM first started promoting it about five years ago (just as it played a key role in the creation of the computer science discipline a few decades ago). Scores of universities around the world have started or are contemplating new academic degree or certificate programs, new journals and books are coming out, and there are more conferences in more places than you could ever possibly attend.<br /><br />I've done my share to develop and spread the idea of service science; there are <a href="http://delicious.com/doc_or_die/ServicesScience"> eight posts in my Doc or Die blog</a> tagged with "service science" that refer to my own papers or conference presentations. <br /><br />Here's some indisputable first-hand evidence that service science has become an epidemic. Six months ago, I was invited to give a keynote speech at a "Joint Workshop of Six Japanese Universities on Service Science" hosted by the <a href="http://www.tsukuba.ac.jp/english/"> University of Tsukuba</a>. When I gave that talk two days ago (27 October 2008), the workshop had been renamed the "Joint Workshop of THIRTEEN Japanese Universities on Service Science." <br /><br />But there's a little disturbing aspect of this. While I believe and endorse the idea that something like service science is emerging as a discipline, I am concerned that many people and institutions are confusing the design of this discipline with the design of the particular curriculum they offer. I published a paper earlier this year titled <a href="http://www.research.ibm.com/journal/sj/471/glushko.html"> "Designing a service science discipline with discipline"</a> in which I contrasted a DISCIPLINE as a "principled model of a coherent body of research and practice" from a CURRICULUM as "a program of study leading to a degree or certificate." No single curriculum can cover the entire discipline, and it shouldn't try! Different universities and their schools have distinct emphases and character, and these differences are inevitable and desirable. They exploit the comparative advantages of each institution and their distinctive faculty composition, student population, industry partnerships and other aspects of the local economy, and so on. <br /><br />This just seems so obvious to me. Berkeley and Stanford both have economics departments, but they don't specialize in the same subjects. It is preposterous to imagine someone telling the four Nobel Prize winners in Berkeley's department that they need to change the courses they teach so that Berkeley can better conform to some standard curriculum model.<br /><br />But that seems to be happening with service science. Every presentation from IBM about service science contains diagrams like the two I've posted here – like the one on the top that shows the model of the discipline, and the one below that compares service science curricula against the background of that model. They're using terms like "sweet spot" to suggest that the "right" curriculum precisely balances business, technology, and people/social/organizational topics, which of course is an indirect (and perhaps unintentional) criticism of academic units with different specializations. Maybe IBM doesn't realize that this is the message that they're sending with these diagrams, but it is the message that people are receiving.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzegJjAvkOAtyX6HiU77g45xQmhEGnKrDfUJL9qbES3_KyUMDJ3hgbEL18QvNdSgFJKYFvEg0xO2T6WweXX_TRtbNP1fJlVP8nm6LUjudOc4KBDyjQ0S-GtYbmlTDW4XECzVSb/s1600-h/SSME-ProgramsNormative.gif"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 265px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzegJjAvkOAtyX6HiU77g45xQmhEGnKrDfUJL9qbES3_KyUMDJ3hgbEL18QvNdSgFJKYFvEg0xO2T6WweXX_TRtbNP1fJlVP8nm6LUjudOc4KBDyjQ0S-GtYbmlTDW4XECzVSb/s400/SSME-ProgramsNormative.gif" border="0" alt=""id="BLOGGER_PHOTO_ID_5262510403150726114" /></a><br /><br />I know that if the <a href="http://isd.ischool.berkeley.edu/">" Information and Service Design" </a> program that we've developed at the UC Berkeley School of Information were analyzed and plotted on this chart, we'd look "defective" in some ways. But our program is innovative, coherent, and takes better advantage of the people, students, and context we've got than anything else we might do. Are we supposed to feel inadequate about this?<br /><br />So one of the main themes in my Japan conference keynote and in meetings I had with different groups of service science professors and students was to ignore this mandate to create a cookie cutter curriculum in service science, and to develop programs that built on their core competencies. People said they were relieved to hear it because they felt pressure to do otherwise. IBM, are you listening?<br /><br /><br />-Bob Glushko<br /><br />tag me: ServicesScience IBM Education UCBerkeleyBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com26tag:blogger.com,1999:blog-24009142.post-58553983134237283132008-10-12T11:30:00.000-07:002008-10-12T11:32:53.134-07:00Document Design MattersA few months ago I wrote about <a href="http://docordie.blogspot.com/2008_06_01_archive.html">an article titled "XML Fever"</a> that I’d written with my Berkeley ISchool colleague <a href="http://dret.net/netdret"> Erik Wilde.</a> We’ve just published another article together called "Document Design Matters" that appears in the October 2008 Communications of the ACM. <br /> <br />We chose the title before we wrote the paper, and under Erik’s forceful leadership of our collaboration the paper evolved in a direction that makes the title less appropriate than it would be if I had been smart enough to be the first author. It would be more apt to title it "Metamodels Matter" but that wouldn’t sound as clever and "metamodel" would probably scare a lot of people away.<br /><br />Here’s an abbreviated abstract of the paper:<br /><i><br />The classical approach to the data aspect of system design distinguishes conceptual, logical, and physical models. Models of each type or level are governed by metamodels that specify the kinds of concepts and constraints that can be used by each model; in most cases metamodels are accompanied by languages for describing models... <br /><br />In this modeling methodology, there is a single hierarchy of models that rests on the assumption that one data model spans all modeling levels and applies to all the applications in some domain. The one true model approach assumes homogeneity, but this does not work very well for the Web…<br /><br />Instead of being governed by one true model used by everyone, the underlying assumption of top-down design, Web data and services evolve in an uncoordinated fashion. As a result, a fundamental challenge with Web data and services is matching and mapping local and often partial models that not only are different models of the same application domain, but also differ, implicitly or explicitly, in their associated metamodels.<br /></i><br />Wilde and I distinguish the native or "system" data model used by an application or web service from the "exchange" model created when it interacts with another one. Exchange models are most often implemented in XML, and this can cause problems because the tree-based XML metamodel isn’t entirely compatible with the graph-based metamodels of RDF or E-R system models. The solution is probably an XML-oriented conceptual modeling language, but we only sketch what one would have to be like in this short paper.<br /><br />The citation for this article is Erik Wilde and Robert J. Glushko. Document Design Matters. Communications of the ACM, 51(10):43-49, October 2008. <br /><br />But you need access to the ACM digital library to find the official version, so we’ve posted (with ACM permission) <a href="http://dret.net/netdret/docs/wilde-cacm2008-document-design-matters/"> an "author’s pre-print version" </a>.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com17tag:blogger.com,1999:blog-24009142.post-65210534770892766742008-09-28T18:10:00.000-07:002008-09-28T18:20:53.761-07:00An Encouraging Sign in the "Bailout Bill"<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghkAeee846xJBc9BLgCZTJB6XbtLq-mXmPHgg8zIKclfbDfP7ByjMTzX_nzj9O7cLLgoLrxT1wG2PEGLTeYkztLdT5HG1_S7_36li_90nxCOTi3yqPfs1CHfM46awQ2aSNr02X/s1600-h/BailoutBillXML.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghkAeee846xJBc9BLgCZTJB6XbtLq-mXmPHgg8zIKclfbDfP7ByjMTzX_nzj9O7cLLgoLrxT1wG2PEGLTeYkztLdT5HG1_S7_36li_90nxCOTi3yqPfs1CHfM46awQ2aSNr02X/s400/BailoutBillXML.gif" alt="" id="BLOGGER_PHOTO_ID_5251246792554153618" border="0" /></a><br />If you're like most people I know, you feel like we're in a "damned if we do, damned if we don't" dilemma with the Wall Street "Bailout Bill." I am philosophically opposed to bailing out people who were greedy or stupid on both ends of the financial pyramid. But this afternoon the text of the proposed bill was published (here's a link to <a href="http://online.wsj.com/public/resources/documents/bailoutbill20080928.pdf">the version hosted by the Wall Street Journal</a>) and on the first page I saw something that made me feel good about the bill.<br /><br />No, not the content - -I haven't had time to fully think about it. But based on the file name embedded in the pdf of the bill -- O:\AYO\AYO08C04.xml -- at least the people doing the publishing work for the bill are doing their best to save our tax dollars by creating the file using XML for efficient production and revision.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-57085581669466788032008-09-28T17:59:00.000-07:002008-09-28T18:10:43.973-07:00I'm not AWOL - I'm pre-emptedI haven't posted to this blog in a few weeks, but I have a really good excuse this time for the dry spell. My last post here described "<a href="http://docordie.blogspot.com/2008/08/another-course-blogging-experiment.html">another course blogging experiment"</a> in which the students in my "Information Organization" course at UC Berkeley would be posting to a <a href="http://blogs.ischool.berkeley.edu/i202f08/">new course-specific blog</a> rather than post here, <a href="http://docordie.blogspot.com/2008_01_01_archive.html">which I tried earlier this year.</a> <br /><br />This has been wildly successful - there's a real blog going on, with several posts a day. But about 1/3 of the time after reading or hearing something in the news that I would normally have written about on "Doc or Die" one of my students pre-empts me by posting to the IO course blog before I got around to posting on my blog.<br /><br />So if you've been suffering withdrawal from my usually insightful posts.... just sign up for the feed for the course blog and you'll get your fill.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-85912200144633716852008-08-31T08:03:00.000-07:002008-08-31T08:05:56.492-07:00Another Course Blogging ExperimentIn the last few years, as blogs and wikis have become widespread, I've thought a lot about whether or how to employ them in the courses I teach. Last semester, when I taught <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/?course=243&view=complete"> Document Engineering</a>, any topic in that course would have been an appropriate subject for this "Doc or Die" blog. So instead of setting up a new blog for the course, I had students <a href="http://docordie.blogspot.com/2008_01_01_archive.html"> use this blog as the course blog.</a><br /><br />Unfortunately, I think that most of the students felt a little intimidated by the suggestion that they should be posting on their professor's blog. So except for the one time that I made it a course assignment to do so, very few students posted to Doc or Die during the semester.<br /><br />We've just started up the fall semester at Berkeley, and once again I have the great privilege and responsibility to teach the only course that every student entering the <a href="http://www.ischool.berkeley.edu/"> Master's Program in the School of Information </a> has to take this semester. The course is titled <a href="http://courses.ischool.berkeley.edu/i202/f08/2008-Syllabus.html"> "Information Organization and Retrieval," </a> which is the name given to it when the school started over a decade ago, but it is significantly broader in scope that that. Many of the topics that come up in the course would be appropriate for "Doc or Die," but not all of them.<br /><br />So this time, we've set up <a href= "http://blogs.ischool.berkeley.edu/i202f08/"> a new blog dedicated to the IO & IR course,</a> and the first assignment for students is to post a news story that concerns a topic in the course (I wanted them to start seeing how IO & IR are deeply embedded in the world they live in, and to take a closer look at the course syllabus). This seems to be working – they are busy posting away this weekend. I suspect I'll end up blogging here about posts my students make over there… or would it make more sense just to comment on their posts on their blog rather than on mine? I guess that would be another experiment.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com4tag:blogger.com,1999:blog-24009142.post-66617861948419800872008-08-21T22:07:00.000-07:002008-08-21T22:19:28.011-07:00Berkeley Calendar Network wins Innovation AwardI feel like a proud parent … or perhaps grandparent or great-grandparent is more accurate (I'll explain that in a minute) … because the <a href="http://events.berkeley.edu/?view=about"> Berkeley Event Calendar Network</a> has recently won the <a href="http://www.ucop.edu/irc/itlc/sautter/welcome.html"> 2008 Larry L. Sautter Award for Innovation in Information Technology</a>, a UC systemwide honor. <br /><br />An "event calendar network" is exactly that, and the motivation for it is quite simple. Before the event calendar network existed, there were literally scores of different Web calendars on the berkeley.edu domain, all with incompatible models of "event" so they couldn't share information. If a distinguished visitor was giving a lecture at our <a href="http://www.ischool.berkeley.edu/"> School of Information </a> that might appeal to people in computer science or business, we'd have to enter the event in three different Web forms to get it on the relevant calendars (and that always seemed like too much effort). There was no easy way to share, syndicate or subscribe to events, which meant that people missed out on events they would have gone to if they'd only known about them. <br /><br />Fast forwarding to today -- because of the calendar network, when you submit an event to your "home" calendar (the <a href="http://events.berkeley.edu/"> "master calendar" </a> is this one), if you mark it "public" so it can be shared, other calendars can transparently include it in their calendars. About 50 calendars are in the network, and new ones join all the time. You can easily can sort events by category or change the display, and each calendar has a customizable CSS "skin" so that it can be plugged into the home page of each department / school / organization in the network. This lets a calendar join the network and get the advantages of event syndication without losing its native look and feel.<br /><br />But like many network-based applications, the event calendar took a while to achieve critical mass, and it has been a long time coming. The reason I feel like the great-grandfather is because I assigned the task of designing an interoperable model of an event for calendars on the Berkeley campus to my Document Engineering class in the Spring of 2003. Yes, 2003 – over 5 years ago.<br /><br />Four of the students in that class – Allison Bloodworth, Nadine Fiebrich, Myra Liu, and Zhanna Shamis – transformed my little homework assignment into their final project as part of their master's degree requirements at the School of Information. They overachieved big time in that effort as you can see from the hyperdocumented design artifacts on their <a href="http://groups.ischool.berkeley.edu/EventCalendar/"> project website</a>, and it was not a surprise to me as their project advisor when they subsequently won the <a href="http://www.ischool.berkeley.edu/programs/masters/projects/chenawards"> Chen award for best final project in 2004</a>. After graduation, Allison went to work for the UCB campus, and she slogged hard for a few years to turn this master's degree project into a deployable application.<br /><br />The graduation award for the project wasn't a fluke. Later that year I co-authored a paper with Allison titled <a href="http://www.idealliance.org/xmlusa/04/call/xmlpapers/228.1432/.228.html"> Model-driven Application Design for a Campus Calendar Network</a>, and this received a "best paper" award at the XML 2004 conference, mostly as a result of Allison's engaging presentation. <br /><br />A year later, when Tim McGrath and I were finishing the writing on our <a href="http://www.docengineering.com/"> Document Engineering </a> book, we showcased the event calendar as a case study that weaves through the book to illustrate the design techniques and modeling artifacts. We used the calendar as a case study not just because it was convenient, but because the interoperability problems it was designed to overcome are typical of every large organization that struggles with incompatible time sheets, expense reimbursements, registration forms, and other administrative documents.<br /><br />So as you can tell, I am a very proud (parent^N) of this event calendar network, and it just pleases me immensely to see it get this award. Now if only the School of Information would join the network, so I could avoid making up reasons why it hasn't even though the project was born there over 5 years ago.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com5tag:blogger.com,1999:blog-24009142.post-60441090709591210972008-08-19T12:47:00.000-07:002008-08-19T13:02:18.073-07:00A New “Information Systems and Service Design” CourseFor most of my professional career I've designed and deployed information-intensive applications, systems, and services. Almost 30 years ago, when I was one of the first handful of people with a cognitive science background to work at Bell Labs, my work in online documentation and content management systems emphasized the "people parts" or "front stages." Over time, especially when I was part of two Silicon Valley start-ups in electronic publishing (Passage Systems, 1992-1996) and B2B marketplaces (Veo, 1997-1999) my focus shifted toward the "back stage" where information is managed, transformed, and moved within and between business systems. <br /><br />But recently, as I've helped to shape <a href="http://www.research.ibm.com/journal/sj/471/glushko.html">the emerging discipline of "Service Science," </a> my goal is to develop methods for designing "<a href="http://en.wikipedia.org/wiki/Service_system"> service systems</a>" that treat the entire network of service components that comprise the back and front stages as complementary and integrated parts. For almost two years I've had a team of graduate students with a mixture of front and back stage design skills thrash with each other and with me to seek some unifying concepts and methods that can overcome the biases and conflicts inherent in their different perspectives.<br /><br />At the risk of stereotyping, here's how I've contrasted these two design approaches <a href="http://people.ischool.berkeley.edu/~glushko/glushko_files/FrontBackStage-April2008.pdf"> in a paper I wrote </a> with Lindsay Tabas:<br /><ul><br /><li><i>Designers with a "front stage mindset" strive to create service experiences that people find enjoyable, unique, and responsive to their needs and preferences. Front stage designers use techniques and tools from the disciplines of human-computer interaction, anthropology, and sociology such as ethnographic research and the user-centered design approach to specify the desired experience for the service customer. They capture and communicate their service designs using modeling artifacts that include personas, scenarios, service blueprints, and interactive prototypes.</i></li><br /><li><i>In contrast, service designers with a "back stage mindset" typically follow different goals and techniques. They strive for efficiency, robustness, scalability, and standardization. Even though some back stage activities are carried out by people, and others carried out by automated processes or applications, the back stage mindset tends to treat people as abstract actors. So instead of modeling the preferences and interactions of people, back stage designers identify and analyze information requirements, information flows and dependencies, and feedback loops. They use concepts and techniques from information architecture, document engineering, data and process modeling, industrial engineering, and software development. Their typical artifacts include use cases, process models, class diagrams, XML schemas, queuing and simulation models, and working software.</i></li><br /></ul>The usual approach for resolving the typical design conflicts and tradeoffs between front and back designers is to create multidisciplinary design teams that explicitly include designers with front and back stage biases. But this is a necessary but insufficient remedy, because what often happens is that each tribe of designers is so convinced of its intellectual and moral correctness that it tries to beat the other side into submission rather than make reasoned tradeoffs. I think this is especially true of relatively inexperienced usability or HCI designers, who find it difficult to accept that business models, legacy implementation constraints, or backward compatibility should shape what gets built. Likewise, some software developers and business managers discount ethnographic field work because the insights about activities and problems seem obvious, but only in retrospect. <br /><br />So I've come to think that a good designer needs a more end-to-end perspective and some familiarity with the concepts and design techniques of "the other stage." And that's why we developed a new course called "<a href="http://courses.ischool.berkeley.edu/i290-1/f08/ISD-Fall2008-Syllabus.html"> Information Systems and Service Design: Strategy, Models, and Methods</a>" that I'll teach for the first time this coming semester.<br /><br />This course covers the entire design process, but rather than teach it from a narrow perspective governed by a single methodology like "user-centered design," it brings together multiple perspectives so that students can learn multiple ways of dealing with the same problem. Many of the topics in the syllabus come in complementary pairs, like "Personas" and "Customer modeling" - where traditional HCI methods get "mashed up" against business/marketing/backend perspectives on the same design problems. Likewise, there are readings on "Ethnography for experience design" (i.e., follow and observe people as they work) with what I call "Ethnography for information system design" (i.e., follow documents and other information objects as they move between people, organizations, and systems). My experience has shown that a combined "document anthropology and archeology" yields much better requirements and insights than either does on its own.<br /><br />One other key aspect of the course is that it discusses a much broader set of design contexts than the typical UCD or HCI design course does. These courses most often consider the design of "one shot" new applications or services where there are no legacy constraints, integration concerns, or product family roadmaps in which functionality emerges over time over a set of related offerings that have to fit into an environment with existing systems and services. <br /><br />So in this new course we'll deal with multichannel designs (that exist in both online and physical contexts, like a web store that also has brick-and-mortar locations), composite applications that combine new information resources with existing ones, and "smart" services that are driven by information collected from sensors or from objects as they move through supply chains or distributed systems. Students will work in teams (which we'll put together to have as diverse or contrasting design experiences as we can) to have an end-to-end design experience in one of these three emerging contexts. I think this will give students a more realistic view of what "design in the wild" is really like.<br /><br />I'll publish my lecture notes <a href="http://courses.ischool.berkeley.edu/i290-1/f08/ISD-Fall2008-Syllabus.html"> on the course syllabus page </a> as the semester progresses if anyone wants to follow along.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com3tag:blogger.com,1999:blog-24009142.post-34446625346264787342008-08-15T16:30:00.000-07:002008-08-15T16:40:13.481-07:00"Dude, you're famous" -- Duane Nickull<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9ap_rSZdl_VSEcd7WcbZJiuynSsSRsW6lqShPaTTVkWwqR743ELnJfKbWw0_J8p1TR-8GSyMDMu4FWzRdMQVEbsVcMlN5QTDIUBgTMJOqxmB1hpnSsaU9sRbhgNYRnCCWQaoK/s1600-h/BobDuaneAdobeTV.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9ap_rSZdl_VSEcd7WcbZJiuynSsSRsW6lqShPaTTVkWwqR743ELnJfKbWw0_J8p1TR-8GSyMDMu4FWzRdMQVEbsVcMlN5QTDIUBgTMJOqxmB1hpnSsaU9sRbhgNYRnCCWQaoK/s400/BobDuaneAdobeTV.gif" alt="" id="BLOGGER_PHOTO_ID_5234892993103160642" border="0" /></a><br />I don't get many email messages with subject lines like "Dude, you're famous" and when I do they are almost always from Duane Nickull. He's a "Senior Technology Evangelist" at Adobe, and has been leading the <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm"> Service Oriented Architecture Reference Model Technical Committee</a> at <a href="http://www.oasis-open.org/home/index.php"> OASIS </a> (an international standards-making organization where I'm on the Board of Directors). Duane and I met about 10 years ago in the technology standards arena when we were both part of the <a href="http://www.ebxml.org/"> ebXML </a> effort to develop and harmonize XML and EDI standards for electronic business -- which laid the foundations for web services.<br /><br />But this description of Duane as a technologist and standards-maker doesn't do him justice and certainly doesn't capture the fact that he's also a brilliant musician, an extreme sports professional, and fun to hang around with. Duane has a fairly traditional blog called <a href="http://technoracle.blogspot.com/"> "Technoracle," </a> but he also has a radically untraditional show on <a href="http://tv.adobe.com/"> "Adobe TV" </a> that mixes technology interviews, code writing demos, and indy music.<br /><br />The reason I am now famous – at least according to Duane – is because he interviewed me for his most recent <a href="http://tv.adobe.com/#v=http%3A//adobe.edgeboss.net/flash/adobe/adobetvprod/duanes_world/59_dua_008.flv%3Frss_feedid%3D1156%26xmlvers%3D2"><br />"Duane's World" episode on Adobe TV</a>. This episode was recorded at the recent annual <a href="http://en.wikipedia.org/wiki/Foo_Camp"> "Foo Camp" </a> get-together at the O'Reilly home offices in Sebastopol, California.<br /><br />In the interview I discuss the motivation and goals for a new course I'm about to start teaching at UC Berkeley called <a href="http://courses.ischool.berkeley.edu/i290-1/f08/ISD-Fall2008-Syllabus.html"> "Information Systems and Service Design" </a>. This is a course that embodies the idea I've talked about here on <a href="http://docordie.blogspot.com/2007/07/bridging-front-stage-and-back-stage-in.html"> "bridging the front stage and back stage".</a> When we design and build "information-driven interactions" we should understand how back stage information contributes to the experience, and we shouldn't focus narrowly on the user interface. Duane came up with a perfect example of the problems this front stage bias can produce: he said that he was annoyed recently when he filled out Web forms to submit his Canadian income tax, only to have them corrected by the tax authorities! A "bridging" design method would have pre-populated the form with the known information, leaving the user to confirm rather than provide it.<br /><br />I'll write something more detailed about that new course soon, and I'll try to make it as entertaining as the interview.<br /><br />Btw, the episode begins with Duane interviewing <a href="http://buytaert.net/">Dries Buytaert,</a> the founder of Drupal, followed by a demo on <a href="http://www.adobe.com/products/flex/features/flex_builder/"> Adobe's Flex Builder</a> tool. And one of the bands whose music appears in my interview is <a href="http://www.myspace.com/22ndcentury"> 22ndCentury </a>. I use Drupal and have tried Flex Builder, and I think I'll listen to more of 22ndCentury.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com4tag:blogger.com,1999:blog-24009142.post-36206819394043393732008-08-09T14:03:00.000-07:002008-08-09T14:08:24.791-07:00The Dark Side of Knowledge ManagementA couple of days ago I came across a 2006 paper by <a href="http://www.usfca.edu/sobam/faculty/alter_s.html">Steven Alter</a> called <a href="http://doi.ieeecomputersociety.org/10.1109/HICSS.2006.196"> "Goals and Tactics on the Dark Side of Knowledge Management," </a> which begins by saying that "the knowledge management literature focuses on the bright side of KM: it barely mentions the dark side, in which knowledge is distorted, suppressed, or misappropriated due to personal or organizational motives."<br /><br />I was intrigued by the title because I'd just <a href="http://docordie.blogspot.com/2008/07/component-content-management-report-ann.html"> reviewed the Component Content Management Report</a>, which by contrast is certainly about the bright side of content management. I also know Alter, and he's a clever guy (maybe even a bit of a "wise guy") who teaches at the University of San Francisco, across the bridge from Berkeley on the "West Bay." <br /><br />This could have been a "tongue in cheek" article, but it's not. It is a brilliant analysis of dozens of news stories in which knowledge was suppressed, distorted, or misappropriated during creation, storage and retrieval, or distribution and presentation phases. Alter uses this "lifecycle x dark side goals" framework to organize the various tactics that he extracted from the news stories.<br /> <ul><br /> <li>For example, <i>"distortion during knowledge creation"</i> occurs when emergency rooms don't run blood-alcohol tests on patients thought to be intoxicated. Insurers can deny reimbursement to patients who are under the influence, so the emergency room doesn't want to have information that would prevent them from getting paid. </li><br /><li><i>"Suppression during knowledge creation"</i> occurs when school districts put pressure on principals to minimize reported dropout rates. </li><br /><li><i>"Suppression during storage and retrieval"</i> occurs when Morgan Stanley falsely claimed to have lost archived email messages that they were ordered to turn over in a lawsuit.</li><br /><li><i>"Distortion during distribution and presentation"</i>occurs when government agencies produce pre-packaged "news stories" with government employees posing as reporters. </li></ul><br />I won't go through all the categories in Alter's framework. But I note that many of the examples reveal a political perspective common in San Francisco (actors in the stories include John Bolton, Dick Cheney, and Donald Rumsfeld), and I'm sure that there are people in red states who would argue that Alter's paper itself is an example of "knowledge distortion during presentation." I'll let you decide for yourself.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com7tag:blogger.com,1999:blog-24009142.post-36803831311836345532008-07-28T13:29:00.000-07:002008-07-28T13:34:24.103-07:00Component Content Management Report - Ann Rockley and CMS WatchI've just read "The XML and Component Content Management Report 2008" from <a href="http://www.cmswatch.com/">CMS Watch,</a> an analyst firm whose name seems too narrow -- it watches a lot more than just content management systems. When I learned about this report I was eager to read it for two reasons. First, I've long read and respected <a href="http://www.rockley.com/"> Ann Rockley, </a> who wrote the report –- she's probably the most highly regarded content management expert in the world (and she <a href="http://www.amazon.com/Managing-Enterprise-Content-Unified-Strategy/dp/0735713065"> literally "wrote the book" on enterprise content management</a>). Second, in a previous life I worked for a company called Passage Systems that would have been discussed in the report if it were still in business, so I was intrigued to imagine how we would have stacked up in the report.<br /><br />(Thanks to web search, I was able to easily find <a href="http://xml.coverpages.org/glushkoPractical.html"> an article I wrote in 1996</a> that says "In 1992 I co-founded Passage Systems, a consulting, software, and data conversion services company that helps companies make the "passage" from print to online publishing.")<br /><br />I don't often rave about things I've read, but the "XML and Component Content Management Report" is an outstanding piece of work. I've seen many reviews of software products, but none has been as comprehensive and insightful as this one. Most reviews present a checklist without explaining the dimensions that frame the product comparison, leaving it to the reader to determine if the products are being compared against a necessary and sufficient set of attributes. Instead, Rockley spends 60 pages explaining the key concepts of component content management before mentioning any products at all. For example, she analyzes the standards of content management – DocBook, DITA, SCORM, and so on – in terms of their maturity and applicability so that a prospective purchaser of a CCMS can confidently assess vendor claims for standards compliance.<br /><br />But the nugget in the report that justifies buying it is a set of content management scenarios that are clearly presented and then matrixed against the product comparison checklist. These include "Complex Reuse," "Complex Translation," "Regulatory," "DITA for Technical Documentation," "Enterprise Component Management," and several others. These scenarios take the pragmatic insights of the first 60 pages and apply them in reviews of every content management vendor I'd ever heard of and a dozen more that I hadn't. <br /><br />This report is indispensable for anyone considering a component content management system. Every page is full of pragmatic best practice wisdom and just oozes an "I've been there, and you can trust what I say" feel. But I didn't expect anything else from Ann Rockley.<br /><br />- Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com173tag:blogger.com,1999:blog-24009142.post-57552608778494471632008-07-14T10:47:00.000-07:002008-12-09T10:12:40.876-08:00UC Berkeley’s "Alice In Wonderland" Semantics for my Parking Ticket<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVUlEW3D3-BvkWd2tdVa3YlDkgTjAditBKhMX4yBkio95SeyWnm-4jNXf6FfNi4EgcNPQm1fSG71xyLQIpJptlu44aa5Qg4OcNkm0H9po7KNqIUNiAr8CWRoHtjagNVcg6OHhP/s1600-h/GlushkoParkingPass-1.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVUlEW3D3-BvkWd2tdVa3YlDkgTjAditBKhMX4yBkio95SeyWnm-4jNXf6FfNi4EgcNPQm1fSG71xyLQIpJptlu44aa5Qg4OcNkm0H9po7KNqIUNiAr8CWRoHtjagNVcg6OHhP/s400/GlushkoParkingPass-1.gif" alt="" id="BLOGGER_PHOTO_ID_5222930176439654914" border="0" /></a><br />A while ago I wrote about <a href="http://docordie.blogspot.com/2006/10/tsas-alice-in-wonderland-semantics.html"> my experiences with the TSA </a> and began my post this way:<br /><br /><i>I was enduring the ritual humiliation inflicted by the Transportation Security Administration at the San Francisco airport when I fell, like Alice in Wonderland, into a semantic rabbit-hole where the TSA used words in ways that made no sense.</i><br /><br />I just had a similar encounter with the <a href="http://pt.berkeley.edu/"> UC Berkeley Parking & Transportation "Service."</a>. On June 23 I received a parking citation for "No Permit for Area" when I parked my car in one of the campus parking lots. But in fact I had left my car with a one-day permit that was appropriate for that particular lot, as you can see in the attached photo here.<br /><br />So when I returned to my car, you can imagine my reaction – there's just no way I should have a parking ticket, and the citation category "No Permit for Area" just makes no sense.<br /><br />Then I read a clarification on the citation that said "scratcher not marked" and again, it didn't make sense to me. As you can see, I have certainly "marked" the month, day, and year on the parking pass. I have X'ed the month, day, and year on parking passes like these dozens of times in the 7 years that I have worked at the university, and have never been cited. I have always assumed that the point of crossing or scratching the pass was to prevent the pass from being used more than once, and I certainly have done that. There is no way this pass could be marked again to indicate another day. So it is simply not true that "scratcher not marked" is an accurate description of my parking pass.<br /><br />But I thought about it some more, and realized that the parking people had apparently chosen to interpret a much narrower and literal view of "scratching" of the parking pass. Maybe the parking enforcement person was having a bad day, or hadn't met his quota, or whatever – but in any case I could now understand that there was an interpretation of "scratching" under which I had not complied with the notice on the pass it is "Only valid on day, month, and year scratched off." <br /><br />Nevertheless, because I didn't like the idea that my car was being ticketed somewhat arbitrarily, I appealed the citation on the grounds that I'd been "marking but not scratching" for years. So even though I might not have literally complied with the requirement, my marking surely limited my pass to a single use, which was the intent of the scratching rule.<br /><br />Of course, my appeal was denied, but as a "courtesy" I was given an offer that if I paid an $18 visitor parking fee my "No Permit for Area" citation would be dismissed. I went to the parking office to pay the fee. When I got there I showed the offer letter to the parking clerk, and tried to explain why I thought they should give me a replacement one-day parking pass for the one that I'd marked on June 23. After all, if my pass had been used, I wouldn't have gotten a citation. <br /><br />Now here's the real Alice in Wonderland part of the story.<br /><br /><i>Parking clerk: Giving you a replacement pass would be letting you park for free on June 23.<br /><br />Me: No, I just paid $18 for a visitor parking fee for that day.<br /><br />Parking clerk: That was a reduced fine. A "No Permit for Area" citation costs $40.<br /><br />Me: So you're really charging me $30, because I had paid $12 for my one-day pass that you didn't honor.<br /><br />Parking clerk: No, you've been charged $18.<br /><br />Me: Well, If my original pass hasn't been used, then can I use it again sometime? This time I will make sure to scratch rather than mark it.<br /><br />Parking clerk: No, you can't use it because it has been marked already.<br /></i><br /><br />At this point it was clear that I was once again in Wonderland talking to Alice, so I gave up.<br /><br />- Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com7tag:blogger.com,1999:blog-24009142.post-13110468669895235922008-07-11T10:27:00.000-07:002008-07-11T10:32:55.723-07:00Is Google Making Us Stupid, And What to Do About ItIt is summertime, and I'm busy rethinking and revising the reading list for my fall course at UC Berkeley ("<a href="http://rosetta.sims.berkeley.edu:8085/sylvia/f07/view/print/202.complete"> Information Organization & Retrieval"</a>). Even though the intellectual foundations and themes of this course like conceptual modeling, semantic representation, classification, vocabulary and metadata design, etc. are timeless, technology and business practices continue to evolve. Besides, if I don't revise the syllabus I'll be bored and my teaching will show it, and I can't let that happen.<br /><br />One article that might make it into my fall syllabus is Nicholas Carr's <a href="http://www.theatlantic.com/doc/200807/google"> "Is Google Making Us Stupid?" </a> in the July 2008 Atlantic Monthly. Carr suggests that the downside of the nearly effortless and immediate information access that the web affords us is diminished capacity to read and focus on printed works, especially books. In Carr's view, the style of reading encouraged or even mandated by the web, in which information is organized in hyperlinked fragments, is "chipping away at my capacity for concentration and contemplation." <br /><br />The title of Carr's article comes from the argument that this fragmentation of reading and thinking is essential to Google's business model, because it and other firms that monetize web use need "the crumbs of data we leave behind as we flit from link to link – the more crumbs, the better… It's in their economic interest to drive us to distraction." <br /><br />Carr is notorious for provocation (remember the debate he started about whether information technology matters?) and of course his article was meant to bait the defenders and disciples of the web into counterattacks. Sure enough, John Batelle and others took the bait, and with an even more provocative title Batelle lashed back (<a href="http://battellemedia.com/archives/004494.php"> "Google: Making Nick Carr Stupid, But It's Made This Guy Smarter." </a> A less rabid reaction came from <a href="http://blog.jonudell.net/2008/06/10/a-quiet-retreat-from-the-busy-information-commons/"> Jon Udell, </a> who suggested that it is up to each of us to find the right balance of big and little information chunks to consume.<br /><br />I tend to agree more with Carr than Batelle. Of course the web makes it incredibly easy to find satisficing information -- to find something that minimally meets an information need -- and that's great if I want to check a fact or temperature or stock price where any source with the information will do. But the web makes it much harder to meet the more intellectually important goal of getting your head around some issue, which you can often most easily do by reading a tightly integrated analysis in a book or scholarly article, because these are very difficult to locate using web search. <br /><br />And this IS partly Google's fault, because Google fundamentally determines relevance by the words that appear on individual web pages. So what you get in results lists are pages that have the search terms, so results listings are cluttered with the blog rants and less comprehensively researched information. Maybe I'm just "old school," but when I need more than facts or news stories I use the <a href="http://www.lib.berkeley.edu/"> California Digital Library </a>to search using the <a href="http://en.wikipedia.org/wiki/Library_of_Congress_Subject_Headings"> Library of Congress subject headings </a> and other more sophisticated search resources, which enables me to find the long and authoritative chunks of information I'm looking for. Not everything on the web has subject-level metadata that is vastly better at identifying relevant content than mere word occurrences, but of course that's because most stuff on the web doesn't justify the additional effort to create it. <br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com4tag:blogger.com,1999:blog-24009142.post-88433118848223697082008-06-24T12:04:00.000-07:002008-06-24T12:13:52.466-07:00XML FeverI've co-authored a paper with my School of Information colleague <a href="http://dret.net/netdret/"> Erik Wilde </a> titled "XML Fever" that has just come out in the July 2008 "Communications of the ACM."<br /><br /><a href="http://dret.net/netdret/docs/wilde-cacm2008-xml-fever.html"> YOU CAN GET OUR PREPRINT VERSION HERE</a> <br /><br />Despite the somewhat silly title, which we modeled after a paper by Alex Bell called <a href="http://portal.acm.org/citation.cfm?doid=984458.984495"> "Death by UML Fever"</a> in ACM Queue a few years ago, "XML Fever" is a serious paper that analyzes misconceptions and problems with XML.<br /><br />For example, anyone who's ever heard me rant about <a href="http://docordie.blogspot.com/2006/08/xml-isnt-self-describing.html"> why XML isn't self-describing </a> won't be surprised that one of the XML fevers is "Self-description delusion." This causes its victims to assume that the semantics of an XML document are self-evident, openly available just by looking at it and understanding the names. Frequently, this strain of XML fever causes great discomfort when the victims learn that XML does not deal with semantics, and that common understanding has to be established through other mechanisms. <br /><br />The abstract says:<br /><br /><i> The Extensible Markup Language (XML), which just celebrated its 10th birthday, is one of the big success stories of the Web. Apart from basic Web technologies (URIs, HTTP, and HTML) and the advanced scripting driving the Web 2.0 wave, XML is by far the most successful and ubiquitous Web technology. With great power, however, comes great responsibility, so while XML's success is well earned as the first truly universal standard for structured data, it must now deal with numerous problems that have grown up around it. These are not entirely the fault of XML itself, but instead can be attributed to exaggerated claims and ideas of what XML is and what it can do. </i><br /><br />The introductory paragraph:<br /><br /><i>This article is about the lessons gleaned from learning XML, from teaching XML, from dealing with overly optimistic assumptions about XML's powers, and from helping XML users in the real world recover from these misconceptions. We frame our observations and the root of the problems along with possible cures in terms of different categories and strains of XML fever. We didn't invent this term, but it embodies many interesting metaphors for understanding the use and abuse of XML, including disease symptoms, infection methods, immunization and preventive measures, and various remedies for treating those suffering from different strains.</i><br /><br />The last two paragraphs:<br /><br /><i>When someone first learns about it, XML may seem like the hammer in the cliché about everything looking like a nail. Those of us who teach XML, write about it, or help others become effective users of it, however, can encourage a more nuanced view of XML tools and technologies that portrays them as a set of hammers of different sizes, with a variety of grips, heads, and claws. We need to point out that not everyone needs a complete set of hammers, but information architects should know how to select the appropriate hammer for the kind of hammering they need to do. And we should always remember that pounding nails is only one of the tasks involved in design and construction.<br /><br />XML has succeeded beyond the wildest expectations as a convenient format for encoding information in an open and easily computable fashion. But it is just a format, and the difficult work of analysis and modeling information has not and will never go away.<br /></i><br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com0tag:blogger.com,1999:blog-24009142.post-46952766937710908472008-06-18T19:21:00.000-07:002008-06-18T19:30:33.361-07:00Service Systems in Taiwan and Taiwan as a Service SystemThis week I've been in Taiwan at a Service Science Faculty Workshop at the <a href="http://www.nthu.edu.tw/english/index.php"> National Tsing Hua University in Taiwan</a> The College of Technology Management there has started a graduate program in service science, as have several other academic units at other Taiwan universities. I gave an invited talk titled <a href="http://people.ischool.berkeley.edu/~glushko/glushko_files/Taiwan-SSME-Glushko-2x.pdf">"A Systems Approach to Service Science Research" </a> in which I reviewed different definitions and modeling frameworks for "Service systems." I also participated on a panel titled "Old Wine in New Bottles" in which different universities talked about their experiences developing courses and curricula, something I've <a href="http://docordie.blogspot.com/2007/07/designing-with-discipline-in-service.html"> written and blogged about. </a><br /><br />I began my plenary lecture with the example of the service experience at hotel check-in, which I've presented in detail in a paper titled "<a href="http://people.ischool.berkeley.edu/~glushko/glushko_files/FrontBackStage-April2008.pdf">Designing Service Systems by Bridging the "Front Stage" and "Back Stage"</a> " (and that I've also <a href=http://docordie.blogspot.com/2007/07/bridging-front-stage-and-back-stage-in.html> blogged about before.)</a> One of the key ideas in that paper is that there may be a "moment of truth" when the quality of a service experience becomes apparent, but that quality is enabled or constrained by many other encounters, even though many of these encounters don't involve or are invisible to the customer, and some of them are even invisible to the frontline ervice provider. This kind of "end-to-end" analysis argues that service quality can<br />best be understood with a systems view of how a service is defined and delivered.<br /><br />But while "Service System" is an intuitively sensible and appealing idea, it is usually talked about in a generic and qualitative way, as in this definition in <a href="http://doi.ieeecomputersociety.org/10.1109/MC.2007.33">a paper titled "Steps toward a science of service systems" </a> by my friends Jim Spohrer and Paul Maglio from IBM research: <br /><i><br />A value co-production configuration of people, technology, internal and external service systems connected to other systems by value propositions and shared information.</i><br /><br />This definition leaves a lot of fundamental questions unanswered. For example:<br /><ul><br /><li>If service systems can be composed from other service systems, what<br />are the primitive components of service systems?</li><br /><li>What rules or patterns govern the composition of service systems?</li><br /><li>Is the "shared information" explicitly specified? What rules or patterns<br />govern specifications?</li></ul><br /><br />So most of my talk at the Taiwan conference tried to put meat on the bones of the service system concept by showing how different people have tried to model them. Because of the great range and diversity of domains that have been described as service systems, no single modeling approach or descriptive formalism is adequate. The simplest descriptions are value chain or structural models that involve qualitative properties of connectivity and intensity. Other approaches describe the relationships and interactions among the components in the service system in more formal and quantitative ways. These models essentially add "typing" to the links in the network description of the service system and some make the relationships functional ones that enable simulation and optimization. Finally, service systems in "information-intensive domains" can best be described using information flow and exchange models that are the scope of document engineering techniques that I've <a href="http://www.docengineering.com/"> written </a> and <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/print/243.complete"> taught </a> about for many years.<br /><br />The conference was attended by over a hundred professors, students, government officials, and industry people. I'm very impressed by the rapid uptake of service science in Taiwan, and it seems like another example where something that began with a lot of hype and fanfare in the US has been more systematically adopted elsewhere. <br /><br />Which brings me to the second theme in this post. One of the main points in my lecture about service systems was that the IBM definition was too broad and vague to offer more than qualitative insights – after all, what does it really mean to say as Spohrer and Maglio often do, that a city or a country could be viewed as a service system? But after a few days in Taiwan, I can understand better what they intend. So Jim and Paul, I'll be less hard on you the next time I talk about service systems.<br /><br />I have been very impressed by how hard Taiwan is working to transform its economy into a knowledge and service one, and it seems profoundly more advanced in just about every way since I was last here about 8 years ago. I took the <a href="http://en.wikipedia.org/wiki/Taiwan_High_Speed_Rail"> high speed train </a> from Hsinchu, where the conference was held, to Taipei, and the "service experience" was first rate. The Hsinchu train station is a stunning piece of visual and functional architecture, and the trains go blazingly fast, over 180 miles an hour. We have nothing like them in the US. I stayed at the Ambassador Hotel in both Hsinchu and Taipei, and when I got to the latter I realized how much the service offerings were being tailored to the different customer segments of each hotel: the former, because it was full of Silicon Valley types, felt like a US hotel, while the latter, because it was full of Asian tourists, felt distinctly different in entrance and lobby design, room décor, breakfast menu. Finally, as I was returning from a late dinner, I was amazed to see students of elementary and junior high ages on the streets, and I was told that they were going home after their many hours of after school studies of the English language.<br /><br />So the "Taiwan service system" is hitting on all cylinders, and while it makes me optimistic for that country's future, it makes me worry about the one I'm heading home to later this week. <br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com4tag:blogger.com,1999:blog-24009142.post-50893038553172926412008-05-30T10:59:00.000-07:002008-05-30T11:02:07.836-07:00Post-It "Signatures" Aren’t SignaturesOn any given day I use credit cards, write checks, request reimbursements, approve time sheets, or complete this or that form. Each of these activities requires me to sign a paper document. When transactions and requests like these are moved online, I no longer sign with pen on paper, but I still am required to produce an electronic signature, perhaps literally with a stylus of some sort or analogically with a login and password. The point is the same – I need to provide irrevocable proof that I am who I claim to be when I authorize some action to be taken on my behalf.<br /><br />That's why I was astonished this week to read this week (in a <a href="http://www.nytimes.com/2008/05/27/business/worldbusiness/27siemens.html"> 27 May 2008 NY Times article </a> by Carter Dougherty titled "Ex-manager tells of bribery at Siemens") about the scheme allegedly used to approve bribe payments. Over 1.3 billion euros worth of suspicious transactions over the past seven years have been identified (for those of you who haven't been following the collapse of the dollar's value, that's 2.1 billion US). And according to Reinhard Siekaczek, a former Siemens middle manager who faces 58 charges of "breach of trust" and is cooperating with prosecutors, he built up "slush funds" by paying for bogus consulting charges so that bribe payments could be made to win contracts. <br /><br />But the role of Post-Its in the bribery process defies logic. People signed Post-Its and attached them to the documents needed to carry out the bribes, That way, according to Siekaczek:<br /><br /><i>The signatories could elegantly remove signs of their involvement if it came to an investigation.</i><br /><br />Now I know that languages are living things, and concepts continually evolve. That's why we recognize that a "signature" no longer assumes a quill pen and inkwell, but can also be performed with a ballpoint pen or electronic stylus. But I think that an intrinsic part of any notion of "signature" is that signatures are intended to be permanently embedded or affixed to the documents being signed. There is just no way that anyone at Siemens who ever signed a Post-It could rationalize that this was an appropriate mechanism for authorizing or recording a business transaction, especially one involving such significant amounts of money. <br /><br />Unless, of course, they had been informed of a new policy at Siemens that established Post-It signatures as equivalent to traditional ones. Given the 270 suspects that prosecutors have identified, including four former members of the top executive group, this new policy would have had to come from high up in Siemens. Would the document describing this new policy have been signed with a Post-It? <br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-48350012892887791562008-05-21T14:48:00.000-07:002008-05-21T15:05:02.433-07:00Unleashing the Masters of InformationWe've just had our <a href="http://www.ischool.berkeley.edu/about/news/topstories/commencement2008"> annual commencement</a> at the School of Information at UC Berkeley, which means we are unleashing another class of "masters of information" on the world. I've always thought it was a little odd for us to be called the School of information, but that's the name (and <a href="http://www.ischools.org/oc/index.html"> we're not alone</a>). I hope that all schools at Berkeley are schools of information (as opposed to "disinformation"or "misinformation"), but given what we do and teach here if any academic unit on campus were to use that name it could only be us.<br /><br />Instead of a master's thesis, which is required by many professional degree programs at Berkeley, the ISchool requires a final project, which is almost always a 2-4 person team effort extending over a couple of semesters. This year there were <a href="http://www.ischool.berkeley.edu/programs/masters/projects/2008"> 16 final projects</a> sorted into three categories. The mix of final projects reflects the wonderful intellectual and curricular diversity here, but a handful are especially relevant to the topics I post about on this blog -- so go back and follow the link to the project list. <br /><br />I'm very proud to say that the two projects that I advised <a href="http://www.ischool.berkeley.edu/about/news/topstories/commencementawards20080517"><br />were singled out</a> by outside judges as prize winners:<br /><br /><a href="http://www.ischool.berkeley.edu/files/FinalReport.pdf">MD:Notes</a> was named the best project in the "Information System Implementation" category. The students were Zach Gillen (the Teaching Assistant in my <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/print/243.complete"> Document Engineering</a> course), Jill Blue Lin, and Kate Ahern.<br /><br /><i>Our product, MD:Notes, is a prototype for an application that improves the hospitals' processes for creating and retrieving progress notes.<br /><br />Our primary motivation for the project was to better understand how public hospitals are making the transition from paper to electronic records, and to design a solution that addresses the hospitals' needs. Specifically, we focused on how two public hospitals in the Bay Area work with progress notes.<br /><br />Progress notes are notes written by a physician to describe the patient's condition during the visit, the physician's assessment and plans for treatment. These notes are an important part of a patient's medical history. Taken as a whole, they tell a rich narrative about a patient's medical past. A progress note is one component of a patient's record consisting of many pieces of clinical documentation.</i><br /><br /><a href="http://www.ischool.berkeley.edu/files/jdi_FinalPaper.pdf">A Digital Clean Slate</a> received the runner-up project award in the "Information Policy and Management"category. The students were Evynn Testa-Avila and Chris Volz. <br /><br /><i>When potentially derogatory information is dismissed from a person's record in the court system, the dismissal is not always registered immediately with various Corporate Data Brokers (CDBs) who provide background checks to employers. This means that errors can appear in background checks and jeopardize chances at employment. In this paper, we present the results of a pilot study that looks at the flow of information from public court records to CDBs and then to employers and job applicants. Of particular interest is how and when errors may be introduced into these records and how processes and systems can be improved to avoid or minimize such errors.</i><br /><br />Both of these projects did very careful and thoughtful document and process analysis in complex environments -- I've called this "document anthropology and archeology" because it involves an iterative cycle in which documents or other information sources may refer or link to other documents, or to people, who can refer to other people or to other documents, and so on. <br /><br />It is very rewarding each year to see the really interesting work that students do here and to contribute to it as a teacher and research advisor. But that always gives me mixed emotions, because it makes me look forward to the next class. So congrats to Zach, Jill, Kate, Evynn, Chris and the rest of the class of 2008, but you have to leave now to make room for class of 2010, so be sure to empty out your lockers in the graduate student lounge.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-52080962434183552042008-05-11T14:00:00.000-07:002008-05-11T14:05:05.328-07:00Document Engineering and User Experience DesignThis past week (8 May 2008) at the <a href="http://www.doctrain.com/west/program_detail/document_engineering_in_user_experience_design/"> DocTrainWest conference in Vancouver </a> I gave a keynote talk titled <a href="http://people.ischool.berkeley.edu/~glushko/glushko_files/DocTrain-Glushko.pdf"> "Document Engineering and User Experience Design." </a><br /><br />My talk was based on some evolving ideas I've called "Bridging the Front Stage and Back Stage" in a <a href="http://people.ischool.berkeley.edu/~glushko/glushko_files/FrontBackStage-April2008.pdf"> paper </a> and talks over the last year. The contrast and conflict I've been thinking and talking about is between information system designers with a "user experience" perspective and those with a "back end" or systems and data analysis perspective. People with the UX mindset focus on the interactions or encounters that people have with systems and services, and thus intentionally or unintentionally discount the contribution of the "back stage" work where materials or information needed by the front stage are processed. For example, if you analyze a web shopping experience from the front stage point of view, you emphasize usability and visual design considerations and don't think about the information exchanges between warehouses, shippers, banks and so on who have to work together if what you order is going to arrive on time. A great user experience on the web site doesn't mean squat if this back stage "content choreography" goes wrong.<br /><br />So I've been saying that it is essential to consider the entire network of services that comprise the back and front stages as complementary parts of a "service system." We need new concepts and methods in service design that recognize how back stage information and processes can improve the front stage experience. <br /><br />My DocTrain talk didn't say very much that was new, but I adapted my message to the technical writing and content management crowd a bit. I just said that another way to think about the front stage fixation is that it gives too much credit to user interface designers for the user experience, and not enough to people who design (and communicate) the documents and document choreography that are necessary to make the end-to-end system work. I'm not trying to take credit away from user interface designers, but they need to appreciate that the back end folks deserve some too. <br /><br />This adapted message resonated with the DocTrain crowd. I had MIT Press ship 2 boxes (32 copies) of the paperback edition of my <a href="http://www.docengineering.com/"> Document Engineering book </a> for me to do a book signing after my talk, and the books sold out with people standing in line. Many of them then went and ordered the book on Amazon, and this jump in sales drove the book to #3000 for a short time (it has now recovered from this hyperstimulation in sales and is much lower now). And I'm flattered to discover today that several people have blogged positively about my DocTrain talk. <br /><br /><i>Antoine Giraud: <a href="http://wordbit.com/doctrain-day-3-content-choreographers-unite/">"Content Choreographers Unite" </a><br /><br /><a href="http://justwriteclick.com/2008/05/08/doctrain-west-2008-bob-glushko-document-engineering/">Anne Gentle</a><br /><br /><a href="http://www.scriptorium.com/palimpsest/2008/05/doctrain-document-engineering-in-user.html">Sarah O'Keefe<br /></a></i><br /><br />So thanks for the encouragement. I hope that Scott Abel invites me to talk again at DocTrain.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com3tag:blogger.com,1999:blog-24009142.post-80853436070048003942008-04-27T15:20:00.000-07:002008-04-27T15:26:58.606-07:00Whining About Wine and ChampagneI've written a lot about categorization and naming because they are not just important concerns in document engineering but also in "making sense of the world" more generally. I've discussed these issues as they apply to <a href="http://docordie.blogspot.com/2006/12/category-craziness-in-decapod-duels.html">lobsters</a>, <a href="http://docordie.blogspot.com/2006/08/sorry-pluto-and-some-thoughts-about.html"> planets, </a> <a href="http://docordie.blogspot.com/2006/03/fdas-naming-police.html"> prescription drugs, </a> <a href="http://docordie.blogspot.com/2006/10/tsas-alice-in-wonderland-semantics.html"> airport security screening,</a> and other equally diverse subjects precisely because they are such fundamental and ubiquitous concerns. And today I get to write about categorization and naming for wine and champagne, prompted by a story in the 27 April 2008 New York Times titled "<a href="http://www.nytimes.com/2008/04/27/world/europe/27champagne.html">Produced in Champagne, but what do you call it?</a>." <br /><br />The point of today's story is that a village in Switzerland called "Champagne" that has been around for about 1200 years is being beat up by France and the European Union and not allowed to use its name for any of its agricultural products, including wine. So it can't label wine it makes as "wine from Champagne" now, even though even though until 2005 this was allowed. <br /><br />And there is especially no way that a winemaker from Champagne in Switzerland can call sparkling wine "Champagne," i.e., it can't call any wine "Champagne from Champagne." According to French law, you can only use this name for sparkling wine if you follow a precisely specified production method using grapes from a precisely specified part of the "Champagne Region" about a hundred miles east of Paris. <br /><br />But this so-called "region" didn't seem like a region to me, because I usually use that word to mean some kind of contiguous geographical area, perhaps defined by explicit features like rivers or mountains or borders. Instead, the "Champagne Region" is defined by enumeration, and it consists of 319 communes (municipalities) in numerous disconnected areas. Being on this list really matters, because CR-designated land is worth 200x as much as adjacent land that is not as lucky to have the CR-label.<br /><br />So perhaps isn't surprising that there is lots of pressure to expand the size of the Champagne Region, and another New York Times article ("<a href="http://www.nytimes.com/2007/12/26/dining/26cham.html">A Tempest in a Champagne Flute" on 27 December 2007</a>) describes the intrigue around a secret plan to add another 40 communes to the lucky CR club. Now I admit that I don't understand all the criteria being applied to decide who wins and who loses, which according to the NY Times are:<br /><br /><i>Champagne's history, geography, geology, agronomy and an obscure field called phytosociology, the study of plant communities.</i><br /><br />Nevertheless, it is a little amusing to imagine that if the debate were really about following the rules or applying scientific principles to the definition of the Champagne Region, wouldn't it be possible that some of the 319 currently lucky communes might be found out as pretenders and kicked out of the CR club? But that doesn't seem to be happening, and the club is getting bigger because global demand for sparkling wine is growing and France's market share is declining. (If you really care about this issue, read Tom Stevenson's <a href="http://www.wine-pages.com/guests/tom/champagne-expansion.htm"> Champagne's €6 billion expansion</a>) to see how what's really going on). <br /><br />Let me end this story about wine naming and categorization with two things closer to home. First, I knew a little bit about the naming rules for champagne because I've visited the <a href="http://www.schramsberg.com/"> Schramsberg Winery </a> in Calistoga California, which bills itself as "America's First House of Sparkling Wine." They don't call what they make "champagne," but they make a point of telling you that they follow the traditional "méthode champenoise" for making it; i.e., "we make it exactly like they do back in France where they call it champagne, so draw your own conclusions." So they want to get you to call it champagne without calling it that themselves. <br /><br />Finally, in that same Napa Valley town of Calistoga there is another labeling fight going on that involves wine of the regular, non-sparkling variety. There was a story the first week of April in the San Francisco Chronicle (<a href="http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/04/07/MN8IV76JA.DTL&type=printable"> "Overhaul of labeling rules stirs up wine wars")</a> about a dispute over regional labeling of wines by the origin of their grapes. A famous upscale winery in Calistoga called <a href="http://www.montelena.com/"> Chateau Montelena </a> petitioned the federal government to create a Calistoga "American Viticultural Area." However, a less upscale winery called <a href="http://www.calistogacellars.com/"> Calistoga Cellars </a> whose grapes aren't exclusively from Calistoga would then be forced to change its name, even though it is located in the town of Calistoga. <br /><br />I'm not going to take a clear position on this California dispute, because I've been to Chateau Montelena (it is a gorgeous winery, with Japanese water gardens etc. well worth a visit) and like their wine, and I don't want to get on their "watch list" and banned from their tasting room and winery. But we seem to be creating these AVA categories pretty rapidly and capriciously, and even if the Calistoga AVA is created, I don't see why the use of a term like Calistoga to mean "grapes from here" has retroactive priority over the use of the term to mean "our company is from here," especially if Calistoga Cellars makes no false claims about the origin of its grapes. Seems like they are getting the Swiss treatment, and like the village of Champagne, they're getting it from the French, or at least from a winery with a French name.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-80069343791662983002008-04-20T16:05:00.000-07:002008-04-20T16:46:05.710-07:00Document Engineering for Microfinance in Developing CountriesWhile I read some papers for my course, <a href="http://courses.ischool.berkeley.edu/i290-17/s08/">ICTD (Information and Communication Technology for Development) reading seminar</a>, I thought of the roles of document engineering for microfinance in developing countries. Microfinance is the provision of financial services, including credit, loans, savings and insurance, to poor and disadvantaged members of society. This has emerged as one of the most effective methods of financial development and poverty alleviation.<br /><br />For this microfinance, I could find two possible challenges that document engineering could address:<br /><br />- first, much of microfinance in India is built upon the grassroots group. Individual members in this group deposit money into a common fund, which is in turn lent to other members at a mutually agreed interest rate. This group sometimes forms larger structures by linking with other groups to form a federation to finance much bigger money. Each person, each group, and federation have their own set of complicated ledgers and forms to store and manage financial transactions. However, there are redundant and unnecessary data formats. So, there have been inefficiency in maintaining overlapping documents to exchange information among difference groups, and form a federation. Therefore, there is room for improving this problem by standardizing documents and data format.<br /><br />- second, there are information asymmetries between groups who are and are not accessible to village banks. Members with easy access can invest in different types of projects with greater returns to scale, which in turn exacerbates polarization even between poor groups. Therefore, equal access to information does really matter. In terms of document engineering, the sharing of information with clear rules and updated news could help eliminate the information asymmetries.<br /><br />ICTD aims at developing the third world using information and communication technology. So, I think there could be a variety of scenarios, which document engineering can play a role for, as in those two examples of the microfinance.<br /><br />-Luke RheeUnknownnoreply@blogger.com2tag:blogger.com,1999:blog-24009142.post-90561926006971547452008-04-10T11:21:00.000-07:002008-04-10T11:26:46.427-07:00Paving (only part of) the Cow PathI've been teaching process analysis and design in my <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/print/243.complete"> Document Engineering course at UC Berkeley </a> and I gave my annual admonition against "not paving the cow paths." I'm not sure where this expression comes from, but it is widely used to mean "don't just automate the AS-IS model" and is almost always meant to be a derogatory comment.<br /><br /><i>…with one exception: I've heard people in the <a href="http://microformats.org/"> "microformats" </a> club use the cow paths phrase with pride when they create little languages that do nothing more than codify ordinary practice…</i><br /><br />But I think that not paving cow paths is essential advice because even though there is usually some benefit to automating previously manual processes, the largest ROI often comes from new business models that were not possible without the automation. <br /><br />This week I used two case studies to emphasize this point about needing to come up with "TO-BE" models. One was about <a href="http://download.intel.com/technology/itj/2005/volume09issue03/art08_rosettanet/vol09_art08.pdf"> Intel's use of RosettaNet </a>to increase the efficiency of its component supply chain. The second was about a <a href="http://people.ischool.berkeley.edu/~glushko/IS243Readings/RFID-and-BI.pdf"> European supermarket chain's plans for RFID </a> to enable demand-driven consolidation and shipment and replenishment. <br /><br />So I note with was some amusement that my wife (also a Berkeley professor) recently received some email "Remittance Advice" from the UC Berkeley Disbursements Office, telling her that she was getting an electronic deposit to our checking account as a reimbursement for some expenses. The campus made a big push a few months ago to encourage everyone to sign up for direct deposits with the promise that it would speed up reimbursements, and who could argue with that? But they didn't do anything on the front end of the process, and there is still no way to submit reimbursement requests electronically. So my wife submitted expenses on paper back in November, and for four months they worked their way along the cow path until they finally reached the paving in the disbursement office. What's the point?<br /><br />The next time I mention cow paths in a lecture I'll emphasize that if all you can do is pave the cow path, at least pave all of it.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com2tag:blogger.com,1999:blog-24009142.post-17520405797036414962008-03-30T07:20:00.000-07:002008-03-30T07:28:50.316-07:00Taiwan Missile Myopia – It’s data quality that matters!This last week (26 March 2008) <a href="http://www.nytimes.com/2008/03/26/world/asia/26military.html"> the US Department of Defense confessed to making an embarrassing mistake </a> – discovered only recently – that a year and a half ago it sent Taiwan four high-tech electrical fuses for Minuteman missile nose-cone assemblies instead of UH-1 Huey helicopter batteries. Because these missiles carry nuclear warheads, most of the commentary about the story has been concerned with nuclear proliferation in general or on the more specific impact on US relations with China, which views any military support of Taiwan as an intrusion into domestic affairs. But I think that focusing on this specific episode – this "Missile Myopia" – is missing a bigger point.<br /><br />I recognize that this mix-up has political implications, but it is probably not uncommon for the wrong items to be shipped from supply warehouses. The DOD hasn't said anything specific about the part numbers or classifications for the mixed-up items, but perhaps they are easily confusable – visually similar (1 vs. l [that's "one" and "lowercase L"]), or transpositions (ab vs. ba) or transformations (abba vs. abaa [doubling errors are common typing mistakes]) of each other. <br /><br /><i>(There is a mini-science about these kinds of confusability and typing errors, and unfortunately it is often exploited by spammers and domain name hijackers [e.g., micorsoft]).</i><br /><br />Or perhaps the part numbers for electrical fuses and helicopter batteries are the same (after all, they certainly come from different suppliers, and every supplier creates his own numbering scheme) and the real mistake is that "classified" or "unclassified" parts were put into the same part of the supply warehouse. <br /><br />By coincidence, less than a month ago in my <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/print/243.complete"> Document Engineering course </a> we read a short case study article from CIO Magazine called <a href="http://www.cio.com.au/index.php/id;637800080;fp;;fpid;;pf;1"><br />"Operation Clean Data" </a> that describes several efforts to deal with bad data. The first is dead-on relevant to this current Taiwan Missile Crisis. It concerns the British military's efforts to clean up the information in its supply chain by reconciling 850 different information systems, and integrating three inventory management systems…<br /><br /><i>To one system, stock number 99 000 1111 was a 24-hour, cold-climate ration pack. To another system, the same number referred to an electronic radio valve. And if hungry troops were sent radio valves instead of rations, the invasion and rebuilding of Iraq wouldn't have gone very far. </i><br /><br />The British military isn't helping us much in Iraq any more, but if it still wants to help us win "the global war on terror" maybe it can send us some of their data cleanup people to help us fix our supply warehouse problems.<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com1tag:blogger.com,1999:blog-24009142.post-11940278482502918382008-03-26T11:47:00.000-07:002008-03-26T11:56:47.868-07:00Turning Your Brand into a DestinationWe are all familiar with places that are named after geophysical features (Land's End, Three Rivers, Spring Mountain Road), after road and highway "architecture" (Five Points, Spaghetti Junction), or after a person with some actual or inspirational relationship to the place (Berkeley, Jefferson City, Tyson's Corner). <br /><br />(In another <a href="http://docordie.blogspot.com/2006/03/bad-names-people-die-good-names-pilots.html"> post here about naming</a>, I discussed how the FAA has made airplane navigation points more memorable by giving regions distinctive semantic "landmarks." For example, the nav points around Montpelier VT are HAMMM, BURGR, and FRYYS, while the series of points that guide pilots into St Louis include SCRCH, BREAK, FATSS, and QBALL).<br /><br />Occasionally a place becomes strongly associated with a business establishment and this name supplants the previous name for it (e.g.,the shopping mall called the <a href="http://www.westfield.com/metreon/"> Metreon </a> is now a more salient place for most San Franciscans than "Yerba Buena Gardens"). But this week I learned of a new twist in assigning names to places to make a business name its original name.<br /><br />A full-page ad in the 24 March 2008 "Business Week" contains an offer by the <a href="http://www.rta.ae/wpsv5/wps/portal"> Roads and Transit Authority of Dubai Metro</a> titled "turn your brand into a destination" that is described as "the ultimate branding and marketing opportunity." <br /><br />The ad says that I can put my brand on a Dubai Metro station of my choice, or one of the two lines in the Dubai Metro Network. It would be intriguing to have a "Bob Glushko Station" in the Dubai Metro, but I don't feel like getting into a bidding war with Coke or Price Waterhouse or IBM. I wonder if the RTA would accept a <a href="http://www.cbn.com/"> Christian Broadcast Network </a> station (I've sent the RTA an email asking about their terms and conditions... I'll post a follow-up if I hear back). <br /><br />But what really intrigues me is why a country as wealthy as the UAE, whose foreign currency reserves are in the hundreds of billions of dollars, could possibly need the money from selling off its naming rights. It isn't like poor <a href="http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/03/02/SPK4VBCAH.DTL"> San Francisco, which has changed the name of its publicly-owned baseball park three times</a> (Candlestick, 3Com, Monster) to raise a few million bucks. And naming rights or no naming rights, everyone here still calls it Candlestick. <br /><br />(No, I'm not talking about the privately-owned baseball park in San Francisco, which has been officially "branded" by its owners as PacBell Park, SBC Park, and AT&T Park and unofficially branded by a lot of us as "Barry Bonds Park" since Barry is why most of us ever saw a baseball game there).<br /><br />-Bob GlushkoBob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com0tag:blogger.com,1999:blog-24009142.post-64863452423307221742008-03-13T17:36:00.000-07:002008-03-13T17:39:19.850-07:00Congratulations to CovisintI was very pleasantly surprised to run across an article in my printed copy of Information Week (25 February 2008) titled "<a href="http://www.informationweek.com/story/showArticle.jhtml?articleID=206801143">Covisint Drives New Niche in Health Care Exchange Market.</a>" The story announced that <a href="http://www.covisint.com/">Covisint </a> will be using its "secure on-demand collaboration platform" to support "the nation's first statewide e-heath network" in Tennessee. But what was the big news to me was that Covisint now hosts exchanges in all sorts of different industries. I had just never noticed, so I want to offer my belated congratulations to Covisint for reasons I'll now explain.<br /><br />It turns out that I have some very significant history with Covisint. I was in charge of XML architecture and standards at CommerceOne in 1999 when automakers GM, Ford, and Chrysler set up Covisint and chose our "Marketsite" software as the "secure on-demand collaboration platform." A joint approach to e-business for multiple automakers made a lot more sense than going it alone because so many suppliers in the auto industry provide materials and components to more than one OEM. This deal was huge for CommerceOne because it was the first significant vertical or industry-focused exchange we'd won – up to then we'd been selling to telcos setting up horizontal, regional exchanges. The deal happened in the fall of 1999 and caused a huge run up in CommerceOne's stock price that I took full advantage of at the end of December when our 180-day post-IPO "lockup" expired and we were allowed to sell stock. I have always felt grateful to Covisint for their vote of confidence in CommerceOne because of this very direct impact it had on my life since 1999.<br /><br />But in the following couple of years Covisint just didn't get the traction that everyone hoped and the original automotive B2B exchange more or less fizzled out, and at the same time CommerceOne went into a tailspin like so many other Internet bubble companies. So after I left CommerceOne and started teaching at <a href="http://people.ischool.berkeley.edu/~glushko/">UC Berkeley </a> in 2002, I didn't pay much attention to Covisint, which by then had been sold and reorganized.<br /><br />I always had a very abstract notion of the "marketplace" platform we invented at Veo Systems (a start-up CommerceOne acquired in 1998) – you can see this in the patents we filed in 1998 (<a href="http://www.google.com/patents?id=PyQGAAAAEBAJ&dq=6125391">like this one</a>) that describe how:<br /><br /><i><br />A market making node in a network routes machine readable documents to connect businesses with customers, suppliers and trading partners<br /><br />The self defining electronic documents, such as XML based documents, can be easily understood amongst the partners. <br /><br />Definitions of these electronic business documents, called business interface definitions, are posted on the Internet, or otherwise communicated to members of the network. <br /><br />The business interface definitions tell potential trading partners the services the company offers and the documents to use when communicating with such services.<br /></i><br /><br />You see — there is no mention of telcos or auto makers or healthcare providers or any specific industry here – it is just a platform on which a market operator hosts services implemented using XML document interfaces. That's what we invented back in 1998, and it is really gratifiying to see how Covisint now embodies this elegant vision as a platform for services in so many different industries.<br /><br />So congratulations, Covisint. <br /><br />-Bob Glushko<br /><a href="http://technorati.com/tag/CommerceOne" rel="tag"></a><br /><a href="http://technorati.com/tag/Covisint" rel="tag"></a>Bob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com2tag:blogger.com,1999:blog-24009142.post-3007383689309246632008-03-12T00:00:00.000-07:002008-03-12T00:56:36.575-07:00Open, Configurable Workspace and the “paperless office”<p class="MsoNormal"><span style="font-size:100%;">Our recent class reading about the “Myth of the Paperless Office” and the case of DanTech reminded me of the recently-built <a href="http://archrecord.construction.com/projects/bts/archives/labs/07_Calit2/default.asp">CalIT2</a> building I used to worked in at UC San Diego.</span></p> <p class="MsoNormal"><span style="font-size:100%;">The layout of the building is very similar to the description of DanTech’s new venue given by Sellen & Harper. It has wide, open spaces with highly mobile furniture that allow people to reconfigure their working environment. Each wheeled desk is equipped with a computer, along with a small, wheeled storage unit to hold documents and office supplies. Hallways around the perimeter are lined with large whiteboards and chairs, encouraging impromptu meetings and contributions. </span></p> <p class="MsoNormal"><span style="font-size:100%;">I did not realize the minimal use of paper in my workplace until I reread this piece. As the authors point out, reducing the amount of paper stored at a desk “[breaks] the shackles” or anchors that tie a user to a bounded physical space. In the case of my former workplace, the open spaces and minimal storage areas, along with the work processes, facilitated the reduction in paper use. However, like the DanTech case, paper is not completely absent from the workplace. As the authors point out, there are many affordances that paper lends to users. In my case, paper was used as reminders of recent tasks or upcoming events, and to take specific meeting notes.</span></p> <p class="MsoNormal"><span style="font-size:100%;">I think paper is too useful to disappear completely from the work environment. Unless technology produces something that can provide/emulate the almost-innumerable affordances and uses of paper, I believe it is safe to bet that paper is here to stay. </span></p> <p class="MsoNormal"><span style="font-size:100%;"><o:p>-Michael Lee</o:p></span></p><p class="MsoNormal"><o:p><br /></o:p></p> <p class="MsoNormal"><span style="font-size:85%;"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:85%;">On a related note, here are links to descriptions of my Interactive Cognition Laboratory colleagues’ works on similar topics:</span></p> <p class="MsoNormal"><span style="font-size:85%;"><a href="http://www.calit2.net/newsroom/article.php?id=800">Studying how layout affects work</a><br /></span></p><p class="MsoNormal"><span style="font-size:85%;"><a href="http://adrenaline.ucsd.edu/external/projects/contAware/ethnoStudies.html">Context Aware Office</a></span><br /></p>Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-24009142.post-35513105188822209632008-03-09T19:15:00.000-07:002008-12-09T10:12:41.417-08:00Synchronizing the World of Commerce<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWC_H-OiwHSWyJ6uxl46lQL4cxJ196ZawQd2ibeSe7dxY6j3BszVcvKp_rOe4spQAlyHtN2_GmlQ6OSm9rnpEexYO_i5ce49Q7Mcm2pTuBgpC6rw1Kr2ORPf4V4VRxwM_6W8BA/s1600-h/UPS-TruckSlogan.gif"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWC_H-OiwHSWyJ6uxl46lQL4cxJ196ZawQd2ibeSe7dxY6j3BszVcvKp_rOe4spQAlyHtN2_GmlQ6OSm9rnpEexYO_i5ce49Q7Mcm2pTuBgpC6rw1Kr2ORPf4V4VRxwM_6W8BA/s400/UPS-TruckSlogan.gif" border="0" alt=""id="BLOGGER_PHOTO_ID_5175931713254753874" /></a><br />My most recent lecture (2008-03-05) in my <a href="http://rosetta.sims.berkeley.edu:8085/sylvia/s08/view/print/243.complete"> Document Engineering course </a> was about the <a href="http://courses.ischool.berkeley.edu/i243/s08/lectures/243-13-20080305.pdf"> "Co-evolution of business patterns and technology." </a> This lecture marks the transition between the first part of the course in which I teach business model, process, and information patterns to give students some abstract conceptual foundations for the second part, in which I teach analysis and design methods for identifying and applying those patterns. <br /><br />One of the themes of this co-evolution is that information about goods now has value independent of the value of the goods. That is, information about where products are, who uses them, and when and how they are used can be worth more than the products themselves. <br /><br />So it was a nice coincidence on the day before my lecture that I was gazing outside my office window and noticed the UPS delivery truck parked in front of South Hall, the home of the <a href="http://www.ischool.berkeley.edu/"> School of Information </a> where I work at UC Berkeley. Because of UPS' ubiquitous brown delivery trucks, most people would think that UPS is in the "delivery business." But it isn't. The slogan on the side of the truck is “Synchronizing the World of Commerce," which emphasizes the information about deliveries that UPS captures and manages, not the deliveries themselves. None of my students knew "what business UPS says it is in" when I asked them during my lecture, but they do now.<br /><br />There have been many other posts here that touch on different aspects and case studies of these "information supply chains." Here are some of them:<br /><i><br /><a href="http://docordie.blogspot.com/2008/02/paperless-international-shipping.html"> <br />Paperless international shipping </a><br /><br /><a href="http://docordie.blogspot.com/2007/01/antonio-your-ships-are-lost-dont-borrow.html"> Antonio, Your Ships Are Lost -- Don't Borrow from Shylock!</a><br /><br /><a href="http://docordie.blogspot.com/2007/03/food-information-services-and-produce.html"> Food Information Services and "Produce Provenance"</a><br /><br /><a href="http://docordie.blogspot.com/2008/02/rfid-may-be-key-to-finding-latest-mad.html"> RFID May Be Key To Finding Latest Mad Cow Case</a><br /><br /></i><br />-Bob Glushko<br /><a href="http://technorati.com/tag/DocumentEngineering" rel="tag"></a><br /><a href="http://technorati.com/tag/Glushko" rel="tag"></a><br /><a href="http://technorati.com/tag/UPS" rel="tag"></a>Bob Glushkohttp://www.blogger.com/profile/18044653585872011020noreply@blogger.com52