Tuesday, July 11, 2006

Google Maps, the fool's gold of mashups

location based services

With Dave Berlind's Mashup Camp and University coming up next week, this seems like a good time to consider why so many of the Web 2.0 mashups out there are with Google Maps or similar mapping services (ProgrammableWeb currently lists 513 mapping mashups out of 815 total mashups). It's not just because of the prime mover example set by HousingMaps, nor simply the eyecandy appeal of presenting data in such a visually rich format. It's not even merely because they're so easy — it goes a little deeper than that.
The real reason was pointed out to me a couple of weeks agoThis is what makes mapping so untypical of mashups in the real world when I was having lunch with Dan Foody, the brains behind web services startup Actional and now CTO of Sonic Software following the acquisition of Actional earlier this year. It's exactly the same mechanism that led to virtually every early demonstration of web services integration being based on stock tickers. It's the predictability of the data format.
The point is that there's near-universal agreement on how to format an address. OK, there might or might not be a city name, not everyone punctuates the same way, sometimes the zipcode's in a different place, but overall the structure's very well-defined, and Google is smart enough to handle most of the variations. It's almost a de-facto microformat, without the angle brackets.
This is what makes mapping mashups so easy, and so untypical of the kind of mashup challenges people face in the real world: the critical data is already structured according to a specification that all of us internalize by the time we graduate from junior school. The same is true of names, dates, time of day, quantities and dimensions — which incidentally constitute most of the building blocks of information that go to make up those few microformats that have been defined — oh, and prices, which brings us back to stock tickers.
Undefined on that list are a huge mass of information points that are necessary for doing business, which is why mashups are making slow progress in the enterprise — and for that matter, why service-oriented architectures are making slow progress, too, which is where Dan Foody is coming from. In the enterprise, there is no semantic commonality and agreement, he explained. Each application and separate database has its own data structure for 'customer', 'product', 'order', 'line item', and so on. This is the semantic minefield that most SOA projects get bogged down in. It's not unusual for a single organization to discover it's got fifty or sixty different ways of structuring a customer record. No SOA infrastructure is capable of sustaining the overhead it would take to mediate between all of those different structures. Converging on a single format is probably unrealistic, but in Foody's view it's essential to consolidate the number of variations into low single figures.
That's why it's a delusion to imagine that Web 2.0 mashups can solve longstanding enterprise integration problems as easily as creating a mapping mashup. Mashups that rely on core, culturally defined and universally agreed informal data structures like names and addresses are misleading outliers. They mask the true difficulty at the heart of the integration problem: "The semantic challenge is what people will come up against," warns Foody. Mashups are a great stimulus to innovation, but they haven't actually made it any easier to link specific items of information from one system to another. They've just made it look easier because they've all homed in on the few information types that already enshrine some form of pre-existing semantic structure.
If Web 2.0 really is a gold rush, this will be the first in history when the people pushing the maps are the ones who've had their fingers burned. Mapping mashups are the fool's gold of Web 2.0 not merely because they produce no revenue, but far more crucially because they add no new semantic value to the integrations they perform. The real wealth creators will be those who offer enterprise mashup prospectors some means of swiftly and manageably reconciling multiple different data structures when they bring separate information systems together

No comments: