Blogger: Joe Maguire
I like out-of-the-way restaurants in sleepy little hamlets. The food might not constitute haute cuisine, but the quaint, low-tech atmosphere offers a stark, refreshing contrast to the circles I usually travel in. How nice it is to peruse a non-drop-down menu.
But I spend so much time thinking about technology, it takes more than a trip to Sap Bucket, Vermont or Tumbleweed, Oklahoma to distract me. Last time I scanned a dog-eared, laminated menu in a roadside diner, I couldn’t help noticing that I was encountering a mashup. The menu contained four different kinds of data, conforming to four different meta-models:
Page one showed a reproduction of a pen-and-ink drawing of the diner, as it looked 70 years ago. (Meta-model: Image data.)
Page two contained a charming (and apocryphal) history of the diner, founded by great-grandmother as a venue for her cherry pie, a perennial prize winner at the county fair and a favorite of barn raisings and church bake sales for generations. (Meta-model: Narrative data.)
Page three contained the menu, with categories for breakfast, lunch, dinner, and dessert. Certain items were flagged as vegetarian, others as “available in children’s portions.” (Meta-model: Structured data.)
Page four contained a map of the area, with “Grandma’s Diner” prominently marked. (Meta-model: Geospatial.)
There was no evidence that any computer technology was used to prepare the menu.
The diner menu shows that humans are perfectly comfortable switching between meta-models. Even the most famished diner knows—instinctively, automatically—that the narrative data should be read sequentially, whereas the structured data can be scanned in any arbitrary order. Life is short; choose dessert first.
This is yet another case where wetware (i.e., human intellectual capacity) outshines software. Getting software to cope with multiple meta-models is tricky. Exhibit A: the profound difference between query and search. Exhibit B, in the form of a question: Why, after it took the computer industry so long to develop mashup techniques, did end users accepted mashups almost immediately?
Users almost never discuss meta-models because they don’t need to. Computer scientists, on the other hand, do quite a bit of lip-flapping about meta-models. This disparity can lead to an erroneous conclusion: That meta-models are the exclusive province of computer scientists. This is a serious mistake, with consequences for requirements analysts who interact directly with users.
The lesson here is this: Computer scientists must know that users employ meta-models, and must learn to distinguish between meta-models that arose organically as a by-product of human culture and meta-models that were concocted by computer scientists to accommodate technological discussions. Call them organic meta-models and invented meta-models.
Organic meta-models are legitimate vehicles for gathering requirements from users. Invented meta-models are not. For data modeling, the most popular invented meta-model in use today is the UML class diagram. UML class diagrams are based on the object-oriented paradigm, which did not arise organically within human culture as a way to organize a certain kind of data. Rather, object-orientation was explicitly designed by computer scientists to promote certain desirable traits in software, including reusability of programming artifacts.
Because it is based on an invented, not organic, meta-model, UML class diagramming is not an appropriate vehicle for requirements gathering with users. That’s why in my decades-long career as a data modeler and requirements analyst, I have never shown an end user a UML class diagram.