Tuesday, June 24, 2008
YOU CAN GET OUR PREPRINT VERSION HERE
Despite the somewhat silly title, which we modeled after a paper by Alex Bell called "Death by UML Fever" in ACM Queue a few years ago, "XML Fever" is a serious paper that analyzes misconceptions and problems with XML.
For example, anyone who's ever heard me rant about why XML isn't self-describing 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.
The abstract says:
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.
The introductory paragraph:
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.
The last two paragraphs:
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.
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.
Wednesday, June 18, 2008
Service Systems in Taiwan and Taiwan as a Service System
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 "Designing Service Systems by Bridging the "Front Stage" and "Back Stage" " (and that I've also blogged about before.) 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
best be understood with a systems view of how a service is defined and delivered.
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 paper titled "Steps toward a science of service systems" by my friends Jim Spohrer and Paul Maglio from IBM research:
A value co-production configuration of people, technology, internal and external service systems connected to other systems by value propositions and shared information.
This definition leaves a lot of fundamental questions unanswered. For example:
- If service systems can be composed from other service systems, what
are the primitive components of service systems?
- What rules or patterns govern the composition of service systems?
- Is the "shared information" explicitly specified? What rules or patterns
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 written and taught about for many years.
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.
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.
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 high speed train 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.
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.