Doc Or Die

It is truly astounding to see how fast the idea of "service science" (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.

I've done my share to develop and spread the idea of service science; there are eight posts in my Doc or Die blog tagged with "service science" that refer to my own papers or conference presentations.

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 University of Tsukuba. 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."

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 "Designing a service science discipline with discipline" 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.

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.

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.



I know that if the " Information and Service Design" 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?

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?


-Bob Glushko

tag me: ServicesScience IBM Education UCBerkeley

A few months ago I wrote about an article titled "XML Fever" that I’d written with my Berkeley ISchool colleague Erik Wilde. We’ve just published another article together called "Document Design Matters" that appears in the October 2008 Communications of the ACM.

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.

Here’s an abbreviated abstract of the paper:

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

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…

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.

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.

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.

But you need access to the ACM digital library to find the official version, so we’ve posted (with ACM permission) an "author’s pre-print version" .

-Bob Glushko

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 the version hosted by the Wall Street Journal) and on the first page I saw something that made me feel good about the bill.

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.

-Bob Glushko

I 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 "another course blogging experiment" in which the students in my "Information Organization" course at UC Berkeley would be posting to a new course-specific blog rather than post here, which I tried earlier this year.

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.

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.

-Bob Glushko

In 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 Document Engineering, 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 use this blog as the course blog.

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.

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 Master's Program in the School of Information has to take this semester. The course is titled "Information Organization and Retrieval," 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.

So this time, we've set up a new blog dedicated to the IO & IR course, 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.

-Bob Glushko

I feel like a proud parent … or perhaps grandparent or great-grandparent is more accurate (I'll explain that in a minute) … because the Berkeley Event Calendar Network has recently won the 2008 Larry L. Sautter Award for Innovation in Information Technology, a UC systemwide honor.

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 School of Information 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.

Fast forwarding to today -- because of the calendar network, when you submit an event to your "home" calendar (the "master calendar" 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.

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.

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 project website, and it was not a surprise to me as their project advisor when they subsequently won the Chen award for best final project in 2004. 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.

The graduation award for the project wasn't a fluke. Later that year I co-authored a paper with Allison titled Model-driven Application Design for a Campus Calendar Network, and this received a "best paper" award at the XML 2004 conference, mostly as a result of Allison's engaging presentation.

A year later, when Tim McGrath and I were finishing the writing on our Document Engineering 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.

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.

-Bob Glushko

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

But recently, as I've helped to shape the emerging discipline of "Service Science," my goal is to develop methods for designing " service systems" 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.

At the risk of stereotyping, here's how I've contrasted these two design approaches in a paper I wrote with Lindsay Tabas:

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


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

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.

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 " Information Systems and Service Design: Strategy, Models, and Methods" that I'll teach for the first time this coming semester.

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.

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.

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.

I'll publish my lecture notes on the course syllabus page as the semester progresses if anyone wants to follow along.

-Bob Glushko

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 Service Oriented Architecture Reference Model Technical Committee at OASIS (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 ebXML effort to develop and harmonize XML and EDI standards for electronic business -- which laid the foundations for web services.

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 "Technoracle," but he also has a radically untraditional show on "Adobe TV" that mixes technology interviews, code writing demos, and indy music.

The reason I am now famous – at least according to Duane – is because he interviewed me for his most recent
"Duane's World" episode on Adobe TV. This episode was recorded at the recent annual "Foo Camp" get-together at the O'Reilly home offices in Sebastopol, California.

In the interview I discuss the motivation and goals for a new course I'm about to start teaching at UC Berkeley called "Information Systems and Service Design" . This is a course that embodies the idea I've talked about here on "bridging the front stage and back stage". 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.

I'll write something more detailed about that new course soon, and I'll try to make it as entertaining as the interview.

Btw, the episode begins with Duane interviewing Dries Buytaert, the founder of Drupal, followed by a demo on Adobe's Flex Builder tool. And one of the bands whose music appears in my interview is 22ndCentury . I use Drupal and have tried Flex Builder, and I think I'll listen to more of 22ndCentury.

-Bob Glushko