Betamax 2.0: the future of mashups?
Complexity gets complicated
Simplicity in software is, I believe, more than just a noble aim; it is essential for successful software projects. However, simplicity should not be assumed just because one particular technology or methodology is being used.
Mashups, discussed recently by Reg Dev reader Aubry Thonon, are a case in point. One element of the hype around mashups is they are simple to build because all you have to do is link together a few APIs and then you are done.
Life is never that simple, though. Building successful, effective, reliable and long- running mashup applications is not a trivial task, and - indeed - is something that creates its own architectural, organizational and implementation problems.
The current, popular, definition of a mashup is of a web-based application that combines data from two or more sources, into a single integrated solution. The most widely cited example of this is the combination of geospatial data from, say, Google Maps, with information on local businesses taken from an online directory or another data source. The end result allows the user to search for, say, a local baker and be presented with a map showing their locations and a brief summary of the sort of products they supply.
A mashup, then, is merely a new kind of integrated solution, albeit one using the web that can be built by anyone with the knowledge and access to a browser! Simple, huh?
No. Mashup developers will encounter integration issues well known to the software and database worlds, for which there are still no off-the-shelf solutions.
Infact, things are going to be a little more complicated in the mashup world. For example, unlike traditional integration, the suppliers of the source data that's mashed up are often not involved in the project, and may never have designed their data to be used in that way. This will create problems as systems do not automatically collaborate with each other.
Here, then, is my list of some of the most fundamental issues:
Complexity of architecture: combining multiple technologies, development styles and integration points in a single application does not a simple solution make. Indeed, while it is certainly possible to achieve a functioning system, the end result may well resemble a spaghetti of code using a pallet of interfaces and frameworks, rather than a cleanly engineered solution that's simple to use or to maintain.
If there's no muck, is there any brass?
Another consideration with mash-ups is that they must inherently be free to use. People won't pay for something that's easy to put together - as Joel Spolsky wrote in his recent article "Where there's muck, there's brass" (http://www.joelonsoftware.com/items/2007/12/06.html).
One might argue that being free to use didn't slow Google down, but the technology behind Google search wasn't easy to make. If someone can make something of value with a mash-up, then anyone else can do the same thing.
So far, I haven't seen a mash-up demo that answers the question "who's going to pay for this?"
Where's the money?
This is always the problem with this kind of "rad, kewl" technology. Usually you can't charge for the mashup code itself, and it's only useful because it works by leeching informations from other sites - quite possibly in contravention to their usage licences.
Mashups are a great demo. But not products.
Watch what we do with gonumber.com...
...we hope to alleviate some of these issues in due course. Not yet, but we're working on it. For now, it's just a humble directory with a few bells and whistles to appeal to the small biz - restaurants & bars in particular. Hopefully, we'll get it right with regard to mashups - the backend is based on some robust semantic web concepts, including RDF. Watch this space! (Sorry, not keen on commercial plugs, but this excellent Reg article caught my eye!)