Wednesday, October 29, 2008


A Vaccination for the Service Science Epidemic

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

Sunday, October 12, 2008


Document Design Matters

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

This page is powered by Blogger. Isn't yours?