Duane Merrill provides a nice little introduction to mashups at IBM’s site for developers. He looks at the origins of the concept in “bastard pop” songs, the common types of mashups that have popped up on the web and the technologies that underpin them. Most valuable, for those thinking about deploying mashups in a business context, is his overview of the technical and social challenges involved in constructing and using them.
One of the technical challenges (which will be exceedingly familiar to corporate IT types) is data integration: Even in a Web 2.0 world, pulling together disparate data sources into a coherent whole is not a cinch. Another is what Merrill calls “data pollution” (which I’ve referred to as Web 2.0’s truthiness problem): the fact that the data you’re mashing up may not be altogether reliable. Explains Merrill: “As part of their application design, many mashups solicit public user input. As evidenced in the wiki application domain, this is a double-edged blade: it can be quite powerful because it enables open contribution and best-of-breed data evolution, yet it can be subject to inconsistent, incorrect, or intentionally misleading data entry.” Data reliability issues are not, I would add, limited to the information that users provide. A lot of public data sources, such as real estate records, have outdated, incomplete or otherwise flawed data. Merrill also briefly mentions the security issues inherent in mashups, which I wrote about yesterday.
In short, the mixed and often uncertain parentage of these new “bastard apps” (my term, not his) is both their strength and their weakness.
“Mashups are certainly an exciting new genre of Web applications,” Merrill concludes, but “before mashups can make the transition from cool toys to sophisticated applications, much work will have to go into distilling robust standards, protocols, models, and toolkits. For this to happen, major software development industry leaders, content providers, and entrepreneurs will have to find value in mashups, which means viable business models. API providers will need to determine whether or not to charge for their content, and if so, how (for example, by subscription or by per-use). Perhaps they will provide varying levels of quality-of-service.” Damn. I thought mashups were supposed to be easy.
UPDATE: Gartner takes a sunny view of corporate mashups. It says today that mashups will “have a high impact on businesses and reach maturity in under two years.” However, the company also warns “that because they combine data and logic from multiple sources, they’re vulnerable to failures in any one of those sources.”
As I’ve said in a number of places before, the idea of an “enterprise mashup” is bunk. In wrapping the notion of a mashup in layers of technology and practice in order to ensure data quality/validation, semantic negotiation, security, QoS, etc, we’ll end up with something that doesn’t look very much like a mashup at all…
And for all the same reasons, I’m convinced that the idea of “businesspeople” creating mashups is equally stoopid.
Both ideas are great examples of techno-determinism.
The idea of a mashup for enterprise apps could be OK if some of the interoperability issues of pulling webapps together is sorted out, so they don’t tread on each others’ toes.
In terms of data pollution, this is not necessarily a mashup issue, and is not going to be solved with ‘standards’. I can’t really write a standard that says that Boston has to keep its real estate records up to date for example.
For data to be trusted in enterprise mashups,
organizations will need to assess the quality of any services they engage – much as they would do now. Providing a library of approved services from which users can pick then gives the organization more control over quality of data (and potentially interoperability), as well as being able to negotiate and control payment for those services.
After all, a bank is more likely to trust LexisNexis for information about potential customers than it is ‘Phil’s Database of People I Know’. By performing the due diligence up front, and presenting the results in an easy to find place, IT can make it easier for users to mashup trusted services rather than any old junk they find on the web.
Hey, sounds like a user friendly enterprise portal to me. Hmm, my employer (Vignette) will be so happy I talked about them for a change!
Nice post!
Cheers
Phil
http://improving-nao.blogspot.com
I wish I had time to post on this and link to you. Sadly, I haven’t so may I just point you at Talis? If you don’t know about it, it is doing neat,trustworthy mashup stuff for library services.
I wrote about one of its experimental mashups for the Information World Review blog recently. If you, or your readers, are interested this will give a start point into Talis’ activities.
http://blog.iwr.co.uk/2006/07/get_at_those_ho.html
The problem of unreliable or misleading data is real, but there is already precedent for improving incoming data. Make data collection an automatic process – think of the way that Amazon makes book recommendations. So long as you are an ‘honest’ browser, you are not required to explicitly state your preferences.
When it comes to mashups, particularly social mashups, it is better to use behavior as an indicator rather than explicit preferences.
Social data – the types of conversations, friends, and events you’d like to be exposed to – are best indicated by your behavior rather than your preferences.
If Amazon only made recommendations based on your denoted preferences, I bet your purchases would end up looking very different. Mashup makers, take note. People usually don’t know what they want until it’s staring them in the face from the sidebar.