Saturday, November 17, 2007

 

An Interrogation in Helsinki


A couple of weeks ago I served as the "opponent" in a Ph.D. dissertation defense by Paavo Kotinurmi of the Department of Computer Science and Engineering of the Helsinki University of Technology. The concept of an outside opponent was new to me – in my own experience getting a PhD from the University of California, San Diego, I had only to survive an examination by a thesis committee comprised of professors from my own academic department with a single "outside" faculty member from the same university. But it seems that outside the US, it is conventional for Ph.D. candidates to undergo a more elaborate and formal ritual with an external examiner playing a critical role. The detailed protocol for dissertation defenses at the HUT specifies numerous details, including the order in which the candidate, his advisor, and the opponent enter the examination room, exact words for opening and closing the session, and of course the dress code. Kotinurmi and his advisor, Professor Matti Hämäläinen, wore black tailcoats with white ties, and I wore my blue and gold academic regalia that indicate my University of California pedigree.

I was invited to be Koitinurmi’s opponent because his dissertation, titled "E-Business Framework Enabled B2B Integration," involved numerous issues that I spent a substantial amount of my professional and academic career thinking about -- the use of electronic documents, and especially document exchanges, in business processes; the role of standards and frameworks in document and business architectures; and the challenges posed when the participating businesses or services differ in the semantics of their documents or processes. In particular, Kotinurmi analyzed several frameworks and specifications for which I had either helped start, helped develop, or managed people who did so, including the eCo Framework, the XML Common Business Library, ebxml, the Universal Business Language, and RosettaNet. Kotinurmi ultimately selected RosettaNet as the framework on which to build an ontology system that would enable the run-time semantic harmonization of the documents being exchanged in supply chains for collaborative design.

Of course, if we completely agreed on everything, there would be no role for me as the thesis opponent. I began the examination by asking Kotinurmi why he sought to close the semantic gap at "run time" rather than at "design time." A design-time approach would have viewed the problem as a one-time cost to transform business documents and processes to achieve interoperability between the participating firms, whereas a run-time approach treats these as recurring costs. The answer, of course, is that treating the problem at "design time" would involve dealing with many business and organizational sociology issues, such as the respective power of the participants in the relationship, and these are not interesting or in scope for a computer scientist.

I followed up this line of questioning with a related one. Kotinurmi's work is grounded in academic discussion of B2B frameworks, standards, and integration approaches, and his literature review is quite thorough (there are 171 citations in his thesis, and I highly recommend it as a good reference source). But I challenged him by telling him that this review was too narrow and that he had equated "nothing is known about this issue" with "I found nothing about this issue in academic journals." We ended up having a good discussion about what he might have learned had he investigated information from vendors or practitioners, such FAQs, product documentation, implementation guides, and discussion lists.

My final line of questioning began by asking what the implications would be if Kotinurmi tried to generalize his work to handle a wider range of document payloads than just the RosettaNet ones. I followed that with questions about the implications of generalizing his work to handle a wider range of business process metamodels. In each case he gave good answers about how he might extend his ontology, but then I asked:

Is there anything inherently different between a process ontology and a document ontology?

There was a long pause. Finally, Kotinurmi said he didn't think so but he didn’t really know. I didn’t know either, and so I thought that this was a good point to end the exam.

We followed the exam with a celebratory reception, and then with a celebratory banquet. And just as there is for the thesis defense, there is a ritual for the celebration party, which goes by the name "Karonkka." This is presumably a Finnish word for "several hours of speeches, toasting, drinking, eating, and so on of the kind you'd want if you’d just survived a 90 minute interrogation about your dissertation from someone you'd met less than 12 hours earlier." During the Karonkka when it was my turn to speak I made a ceremonial gift of an autographed copy of my Document Engineering book and kidded Kotinurmi that if he'd read if before his examination he would have had an easier time.

I enjoyed my brief trip to Helsinki immensely, not just because I'd never been there and found it to be an interesting city, but because it was gratifying to travel 7000 miles and then have an intellectually stimulating discussion with someone with an ease as though we'd worked together for years. I also met several other people from HUT who are working in areas related to my more recent research on service design, and I expect that we will collaborate some. But when I return to Helsinki for a longer visit, it will be in the summertime and it won't be so dark and so damp.








-Bob Glushko

Comments:
This comment has been removed by the author.
 
So his only reason for choosing to reconcile at run-time versus design-time is because he, as a computer scientist, didn't feel like dealing? Did you except that answer?

I guess it is adequate enough that he can acknowledge that there are issues at design-time that he is incapable of handling.
 
If Koitinurmi had been a business or management student, he'd have looked at how companies negotiate solutions to interoperability problems -- or how the firm with less power accommodates the one with more power in their business relationship. But he's a computer scientist, and thus focused on a technical solution. The technical solution at run time is much more difficult to implement, so you can given him credit for that even if in the real world it might not be the usual way to go about it.
 
Post a Comment

Links to this post:

Create a Link



<< Home

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