Comments on: There is No Such Thing as a Data Mashup

By: In a Tweet for Twitter « Web 2.no?

In a Tweet for Twitter « Web 2.no? — Thu, 18 Mar 2010 09:05:05 +0000

[...] http://blogs.gartner.com/anthony_bradley/2009/04/13/there-is-no-such-thing-as-a-data-mashup/ Comments RSS feed [...]

By: Anthony Bradley

Anthony Bradley — Tue, 28 Apr 2009 17:33:41 +0000

Agreed, and I would argue that data design and information architecture are central to any systems interoperability certainly not just enterprise mashups. This is why we talk about the importance of mashup enablement. However, mashup enablement is about exposing capabilities as mashable which certainly is improved by the use of RSS, ATOM, etc. but that won’t give you mashup interoperability. The challenges of syntactic and semantic interoperability will still persist. An underlying information model or other means of mapping the data from multiple mashable sources is still required regardless of the individual source’s data exposure formats and protocols.

By: Nick Gall

Nick Gall — Mon, 27 Apr 2009 18:42:19 +0000

Whether “data mashup” is a useful term embraced by users or merely a term foisted on the market by vendors I will leave for others to debate. I will claim that data designs can be more or less “mashable” and that this is the most important aspect of mashup architecture. Thus it is data designs (or whatever you want to call the concept, eg,schemas, data models, information architectures), such as RSS, ATOM, JSON, GData, that are most important to “mashability.” For a good discussion of this concept see http://derivadow.com/2007/12/28/web-design-20-its-all-about-the-resource-and-its-url/ .

By: Anthony Bradley

Anthony Bradley — Wed, 15 Apr 2009 20:50:55 +0000

I like the data harvesting terminology and patterns you use in the book and much prefer that terminology to data mashups. Data harvesting is more of an umbrella term where mashup enabling of existing systems is one goal of data harvesting. I am using mashup enabling of existing systems building upon the well known terms of web enabling and service enabling.

Anyway, I appreciate the dialog and look forward to finishing your book.

By: Mike Ogrinz

Mike Ogrinz — Wed, 15 Apr 2009 19:47:48 +0000

Thanks for the quick reply (see, I can sprinkle those smiley faces in there as well). And don’t forget you got a rough-cut of the book, though I cant say I made any edits to the sections you mention.

I think we share very similar concerns. Last Dec, I started a thread over on the book’s companion site called, “Are mashups all hype” where I wrote:

“At this nascent stage of their development, I will not argue that there are not some clouds of uncertainty surrounding mashups. And disparate vendor marketing is partially to blame. Let’s work together to bring clarity to this space”

So I can hardly complain when you make a bold step to address this issue. As for “data mashups” being “enterprise mashups”.. hmm – I’ll plead writer’s fatigue on that one. Sounds like a moment of stupidity (like reading Gartner blogs while I’m on vacation in St. John )

In my defense though, I think the set of “core abilities” (Data Extraction, Data Entry, Clipping, Support for Open Standards, Transformation, Visualization) on which all the mashup patterns in my book are based are very similar to the 3 criteria you put forth.This watermark eliminates tools like Excel, portals, etc. And hopefully budding mashup builders will use these criteria to bring clarity to any vendor discussions they wind up having.

By: Anthony Bradley

Anthony Bradley — Wed, 15 Apr 2009 14:11:48 +0000

We need to remember there is a fundamental disconnect in the industry right now with mashups. Vendors more and more are saying, “When you get down to it, everything is a mashup.” While clients are asking, “What is a mashup really, and why should I care?” I sit between the two and try to help our clients understand what is unique about mashups and why is that uniqueness valuable.

By: Anthony Bradley

Anthony Bradley — Wed, 15 Apr 2009 13:56:00 +0000

BTW, I met Mike and he gave me a draft copy of his recent book, “Mashup Patterns: Designs and Examples for the Modern Enterprise.” I liked Mike right away and I appreciate his bravery in handing an analyst a copy of his book. Notice all the smiley faces.

By: Anthony Bradley

Anthony Bradley — Wed, 15 Apr 2009 13:50:16 +0000

Mike, Thanks for your reply. BTW, I am reading your book and will review it in this blog shortly Let me address a couple of your comments.
1. JSR-168 is not an open Web standard and therefore doesn’t qualify. However, portals are moving quickly to consume Web standards and soon there may be no distinction. They will be getting far more flexible.
2. Yes, very early on with mashups there was some hacking required but that was relatively embryonic and before the big mashup movement. I don’t think you will argue that easier is better and easy is a foundation of mashups (although maybe with your 2+ million patterns you may think they are more complex than I do
3. RSS is a feed not a mashup. A reader that mashes multiple feeds is the mashup application. In your book you have a set of “Harvest” patterns. I’m all for that. Call it Data Harvesting not Data Mashups. You have yet another definition of data mashups in your book where you call it an alternative to the term “Enterprise Mashups.” I’ll wait for my review to address that

4. You hit on the tough one which is the “maintaining their essence” criteria. I admit it sits on the line between criteria and best practice but it is so important that I pushed it over to criteria. I don’t believe enterprise mashups will be successful without this criteria. We use this one to differentiate mashups from the variety of other integration techniques where the capabilities are homogenized (e.g., BI/DW reporting). As an enterprise user you certainly should care and know where the capabilities are coming from. In fact you should be able to choose based on that knowledge.

Finally I will say that you don’t really define mashups or enterprise mashups in your book, you dance around it. You do state that, “All composite applications are mashups but not all mashups are composite applications.” This is seriously flawed. Under that umbrella portals, SOA orchestration, sharepoint web parts, spreadsheet linking, and maybe even tiling of several open windows would qualify as mashups. I am trying to hold to a clear mashup definition upon which you can hang unique benefits. You have turned mashups into everything and therefore into nothing

By: Mike Ogrinz

Mike Ogrinz — Wed, 15 Apr 2009 01:50:52 +0000

I think you are missing an important point in your harkening back to the early days of mashups. Remember Paul Rademacher and HousingMaps.com (the “first” mashup”), which sprang from an ad hoc combination of craigslist and Google Maps?

Mashups began as “innovation without permission” in both the computer + music space. Sure, this sentiment doesn’t fit well with a cut & dry technical definition, but I think somehow we need to capture the spirit that brought us mashups in the first place. (side note: mashups have spread to a third form as people mix Christian Bale rants w/ YouTube videos. But I digress..)

I have some other concerns with your definition:
>>1) (data, logic, and visualization)
This would seem to contradict w/ some of the open standards listed in #3. RSS doesn’t have a visualization component, for example. You might counter that an RSS Reader is the visualization – but the Data Mashup vendors might fire back that the tool (e.g., widget, spreadsheet, etc) that ultimately displays the data they provide is theirs After all, isn’t some form of output inevitable?

>>2) you as the creator and/or user know explicitly where the capabilities came from
I’ve used lots of mashups to find cheap gas, restaurants, etc. And I don’t know where the data comes from. Maybe it’s 1 site – maybe hundreds. I don’t really care. I’m just happy to have the help I need. You are completely right that this presents huge governance, security, auditability, etc issues – especially within the enterprise. But if we immediately disqualify apps that don’t credit their sources as not being true mashups, I think we’d be throwing out some good stuff. This strikes me as more of a “best practice”.

>>3) Mashups employ open Web-based technologes such as HTTP, XML, XHTML, RSS, and ATOM.
Ideally, yes. But the first computer mashup (again, housingmaps.com) didn’t. Paul wrote a custom parser for cragislist and kludged his way into Google Maps before it was officially opened up. I love open protocols and standards. But I love a good hack, too. If providing a new solution means getting my hands dirty – so be it. In fact, some content owners have only chosen to provide an API *after* people started mashing up their data the hard way.

Another side point: By your definition, Portals easily qualify as mashups if we add an open standard like JSR-168 to your #3. Most of the mashup enablers you list can spit out content in this form (and by extension that would make the portal vendor really a mashup platform??) To me portals aren’t mashups because they don’t give the user any/enough control. Even with personalization the user is limited to what the portlet creator opens up for customization.

I completely agree that there are EII and EAI vendors who have jumped on the mashup bandwagon. At least they have the decency to call it a “Data Mashup” tool and not just a “Mashup” one. You know right away to look closer at these guys I think the bigger danger is the BPM and BPEL guys who are suddenly saying they are now a mashup product.

By: Anthony Bradley

Anthony Bradley — Tue, 14 Apr 2009 21:56:56 +0000

Also, your definition of mashup is far too broad. Under your definition, most portals, many SOA orchestration apps, numerous BI reports, and a host of other systems integration initiatives would qualify as mashups.