Sunday, March 26, 2006
I’m not opposed to the idea of mash-ups. Raymond Yee is teaching a new class this semester called "Mixing and Remixing Information” at UC Berkeley’s School of Information (where I also teach), and students seem to be having a great time in it, including those who didn’t enjoy more traditional computing courses. There is definitely great appeal for a user to mash-up in a couple of days an application that might have taken a real programmer weeks or months in the old days. But I guess I’m just “old school” because I still advocate substantially more systematic and analysis-intensive methods for designing and implementing web applications.
And I am truly amused whenever I hear that some mash-up has been acquired for some ridiculously large sum by Google or Yahoo or someone else. It’s like 1999 all over again when an interesting web site or even just the idea for one could pass for a business plan. I still have on the back of my office door one of Hal Varian’s classic monthly “Economic Scene” articles from the NY Times (from February 2001). It is titled “Comparing the NASDAQ bubble to tulipmania is unfair to the flowers” and ends with this:
The Internet was supposed to remove all barriers to entry, encourage competition and create a frictionless market with unlimited access to free content. But, at the same time, it was supposed to offer hugely profitable investment opportunities. You do not have to have a Ph.D. in economics to see that both arguments are rarely true at the same time.
So if a mash-up can be done with almost no effort, then it isn’t going to enable any sustainable business advantage. Smart entrepreneurs will avoid calling their composite applications “mash-ups” if they are looking for investors or acquirers.
Tuesday, March 21, 2006
Bad Names -> People Die; Good Names -> Pilots Smile
I don't know much about aviation, but these navigation points (intersections of the radial signals from ground beacons or satellites) are used by pilots to navigate, and if they aren't memorable, a pilot might set autopilots to fly to the wrong locations. When planes fly to the wrong place they might run into each other or to mountains. So poorly designed names could cause people to die.
Nancy Kalinowski is the FAA's Director of Airspace and Aeronautical Information Management, the department that assigns these names. Way to go, Nancy -- and there are some people at the FDA who could probably use a nudge to be more customer-oriented in the name game.
And while it was neat to see two stories about naming in the Wall Street Journal in just a couple of days, too bad they were assigned to different authors. It would have been provocative to contrast the FDA and FAA naming philosophies in a single article.
FDA's Naming Police
Anyone who works with information models knows how difficult it is to create good names for things and my UC Berkeley course syllabi for Information Organization and Retrieval" and Document Engineering and Information Architecture" include lots of readings and case studies that rigorously demonstrate that. My favorite is a paper called What's in a name" that contains wonderfully deadpan advice about choosing good names:
If one person thinks of a “shipping container” as being a cardboard box and another person thinks of a “shipping container” as being a semi-trailer, some interesting conversations regarding capacity can occur.
So I think it would be great service to our field if the FDA were to publish its "name design rules" or provide access to its name testing software. But I suspect that the rules and software are a little shaky and the FDA is reluctant to make them more transparent.
Sunday, March 19, 2006
At InfoWorld’s SOA Executive Forum in San Francisco this past week Jon Udell moderated a panel about different communication methods used by services. The panelists discussed the range of options from coarse-grained transfer of complete business documents – orders, invoices, and the like – to remote procedure calls with small sets of data. You can make arguments against big document exchanges on the basis of communication efficiency, but you can also make arguments against lots of small information exchanges because of the extra overhead needed to maintain state while all the little exchanges are carried out.
But the best argument for coarse document exchanges is that if you go that way you’ll be making a conscious design choice and almost certainly have invested some effort into designing the document models or evaluating standard document ones. The documents you exchange will more likely be ones that are easy to process because they’ll have unambiguous semantics and use robust code sets and identifiers. They’ll be easier to reuse across a range of related partners and services.
This isn’t to say that fine-grained information exchanges can’t also be well-designed with interoperable semantics. But many proprietary APIs are getting turned into web services by tools that do little more than slap angle brackets around "get" and "set" methods, and you often get what you pay for when you adopt these low-cost “automatic” design techniques.
Of course I’m biased. My book is called Document Engineering, not RPC Engineering.
Wednesday, March 15, 2006
Standards, Monopoly, and Interoperability
Jon Udell (not “John”) writes in “An Argument Against Standards” that standards are an inferior solution to the problem of technology monopolization. Open source is said to be a better solution because by abolishing ownership of the core technology, competing implementations are forks that are easily distinguishable from the standard.
That’s partly right, but misses the point that standards don’t just exist to prevent one party from monopoly – they exist to encourage interoperability. By encouraging a thousand flowers to bloom/fork, open source discourages interoperability.
I admit to being biased in favor of standards, having been involved in lots of standards efforts in the last decade (like xCBL, ebXML, and UBL) and am an elected member of the Board of Directors for OASIS, a standards organization. I am also favorably disposed towards open source. OASIS has been trying to establish constructive relationships with the open source community, but the thousand flowers problem is somewhat of a barrier to that. We’d love to set up a meeting with the CEO of open source.
Tuesday, March 14, 2006
"Unselling" of Generic Drugs to Physicians
So a somewhat disturbing article in the Wall Street Journal on 13 March 2005 about how Pennsylvania is trying to reduce its exploding drug costs for state employees by having "unsellers" visit doctors to pitch generic drugs reminds us that some information exchanges may not be completely trustworthy and automatable. Drug firms have long used people called "detailers" to pitch free samples to doctors, and this article reports how seriously the drug companies track each doctor's prescription habits by mining transaction data from pharmacies. These detailers are very effective at getting doctors to prescribe proprietary and hence more profitable drugs. Pennsylvania is now fighting back using the same techniques against the drug companies.
Electronic Health Records... around the corner or over the cliff?
In my Document Engineering and Information Architecture course at UC Berkeley we recently discussed an August 2005 case study article from the Annals of Internal Medicine called “Electronic Health Records: Just around the corner? Or over the cliff?” Unlike many case studies that strive to present the facts in the best light, this one tells the story of a small medical office’s efforts to adopt electronic health records and other electronic documents with unexpected honesty… maybe naïve honesty. I highly recommend it to anyone considering a document automation effort, especially in healthcare.
Reducing costs and improving efficiencies by automating repetitive document processing within its office and within its “ecosystem” of labs, clinics, pharmacies, and 3rd party payers were the primary motivations for adopting a system. Unfortunately, the staff and physicians had grossly unrealistic expectations about how easily they could learn to use the system and didn’t count on having to radically redesign “15 years of accumulated workflow” to make it work. Furthermore, much of the pain and productivity loss was self-inflicted. Without evaluating any alternatives, they chose a system that imposes a rigid repertoire of 24 document types that that won’t let any document be filed unless it has been assigned to one of those types. And instead of preparing electronic records for their existing patients ahead of time, the staff waited until patients came for appointments to begin any legacy conversion.
Somehow these folks got it all to work, and they say that they are now better physicians and wouldn’t go back to the paper document processes. But I suspect that the lessons they report in this article will be learned the hard way by many other physicians – maybe because doctors have to be smart, they can’t believe that document automation can be that challenging.