Sunday, April 23, 2006

 

Disciplining Services Science

Last week I attended a conference on "Education for Service Innovation" at the National Academy of Sciences in Washington DC. A couple dozen people from academia, industry, and the government met to discuss the emergence of "services science" -- a hybrid academic field that seems to be emerging from the fuzzy intersection of economics, computer science, information technology and systems, document engineering, law, management, industrial engineering, and organizational sociology to provide perspectives on the evolution of the information and services economy and insight about the services lifecycle. (Steve Lohr mentioned this event in a April 18 2006 NY Times article). IBM has been leading the charge -- I recommend their excellent compendium of Services Science Stuff -- but that's not surprising since IBM, like many other technology firms, has seen its revenue mix shift profoundly toward services in recent years.

Several universities are creating courses and curricula on the services economy and on the design, implementation and deployment of services, including UC Berkeley, where I'm part of a small faculty group developing a Services Science, Management, and Engineering (SSME) certificate for master's students in the School of Information, in the College of Engineering, and in the Haas School of Business.

I think that Berkeley and North Carolina State are the only universities with programs that are called "SSME" -- but that's only because some other schools like Penn State, RPI, Maryland and ASU have already been teaching about services in their departments of Industrial Engineering, Decision Sciences, Business, or Management.

I gave a talk about our efforts at Berkeley, and I raised the bigger question about the relationship of a discipline of Services Science to the various curricula that are springing up. A DISCIPLINE is a principled model of a coherent body of research and practice, while a CURRICULUM is a set of courses or program of study leading to a degree or certificate. The distinction seems pretty important, because the SSME programs that emerge are going to be pretty different, reflecting the emphases and character that reflect the history, location, faculty, typical employers for their students, etc. of the universities or departments that create them. I think a model of a discipline can generate many different curricula and can be used to assess and compare their coverage. Without some intellectual foundation and principles that are explicitly shared by all the curricula, their surface differences will make it hard for a Services Science to mean anything.

So what we're doing at Berkeley is somewhat different from the other universities. Instead of starting from any existing curriculum or course, we're asking "What are the key concepts, themes, and challenges that a SSME discipline should encompass" and generating questions that the disciplines that are coming together in Services Science should be able to answer. For example:

We're not quite there yet, but we are developing new courses in Services Science that will be organized around these kinds of questions. We need to discipline ourselves to make this happen by the Fall semester, because we are already scheduled to teach the first of these new courses, one called "The Information and Services Economy."

-Bob Glushko

Sunday, April 16, 2006

 

The Politics of Document Construction

Some students in my Document Engineering and Information Architecture course have encountered the politics of document type construction in their class project to analyze the processes and document flows involved in faculty reviews and promotions. What looks on the surface to be an interesting but straightforward analysis and redesign of a form is turning out to be anything but that, and in talking to the students I’ve realized how much the construction of documents can embody political and organizational power considerations.

The processes center around a form called the "bio-bib" that every professor has to fill out annually. The stated purpose of the bio-bib is to collect from each faculty the biographical (i.e., key events and accomplishments) and bibliographical (i.e., publications) information that are the fodder on which reviews and promotions are based.

The bio-bib form is extremely broad in its coverage, with sections for Teaching, Publications, Committee Service, Professional Activities, Appointments, Awards, and so on. Each of these sections is highly detailed; for example, the Teaching section distinguishes activities involving undergraduates, master’s students, PhD students, and post-docs; the Publications section distinguishes many varieties of peer-reviewed and non-peer-reviewed articles, books, and patents; and there are even nine subcategories of Professional Activities.

We can’t find "change logs" or design rationale for the bio-bib, but you can imagine that the highly complex and nuanced structure of the form reflects a history of heated debates and complaints about the value of some kind of activity or publishing by a professor. For example, the last sub-category of Professional Activities is "Efforts made in support of the University's Affirmative Action goals."

But the implicit design goal to make the bio-bib fair to everyone has created a form that everyone hates to fill out. No matter how much you accomplished, when you’ve completed your annual bio-bib you feel like a failure because you are staring at a sparse form because there is no way you have something to report in most of the categories.

You might also think that being fair makes it sensible that every professor, regardless of discipline or department, fills out the same form. But this assumes that all the categories mean the same thing for every professor, and that’s not so. For example, while you’d think that publishing in a peer-reviewed journal is always preferable to a non-peer-reviewed one, law professors seek to publish in law reviews, in which their papers are selected by law students. A computer scientist would probably get no credit for publishing an article in a student-edited journal.

In addition, it is hard not to think that every list of subcategories of biographical or bibliographic events is ordered in some principled way that reflects their weighting or value in a professor’s review. Many of things I do are "down at the bottom of the list" in their implied value (for example, "consulting" is many steps below "serving as a reviewer or editor"). So I cheated and listed my service as a member of the OASIS Board of Directors (a standards organization), as "Service to scholarly or professional societies" because the latter is #3 in its category.

I could go on and on here, but I should let my students discover some of this for themselves (and then I could write in my bio-bib that I did a good job mentoring their project).

-Bob Glushko







Sunday, April 02, 2006

 

Mashware

My Bashing Mash-ups post has itself been bashed by some folks whose opinions matter to me so I need to try another way to express the point I was trying to make. I wasn't bashing the idea of platforms for mashups - i.e, intelligently designed APIs that expose functionality for other people or services to use. I was bashing the notion that people were going to build serious enterprise applications that way (even though the phrase "enterprise mash-up" seems to be well along the hype curve). A huge problem for enterprise applications is getting all the different information sources and silos to make sense to each other, and this semantic integration challenge is simply too difficult to attack with the level of sophistication I've seen implemented so far in most mash-ups. Take a look at any of David Linthicum's books on application integration (or just read his blog called "A CEO's Guide to EAI, SOA, and Business Integration") for war stories. Enterprise applications aren't assembled in a weekend, but that seems to be the typical effort expended in creating a mash-up. So we're at very different points on the continuum.

Of course, maybe my dispute is just about the names of things, and we all know how contentious names are. Perhaps we're just expanding the notion of "mash up" to include any combination / integration of information from multiple sources, and we can dispense with making any distinction between the categories of mapping and transformation tools, integration servers, message-oriented-middleware, process control engines, EAI, etc. and just call it all "mashware." When every use of software-as-a-service is viewed as a mashup, I'll surrender and stop thinking of mashups and enterprise apps or complexly-choreographed web services as being on a continuum, but until then let's not eliminate all nuance in our discussions about building things.

-Bob Glushko

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