To the man with a hammer, every problem looks like a nail. To the marketer needing sizzle, is every application a mashup? Apparently so. Just like the unfortunately named Web 2.0, which says it all, and therefore says nothing, I see the name mashup applied to lots of things that really aren’t mashups. It’s a shame, really, as mashups enable an entire new category of applications and ways to write them. When people start naming their guinea pigs mashups, it’s time to start putting some definitions together. So, exactly, what is a mashup?

A mashup is an application that uses
1) modern Web integration technologies
2) to take content or services from two independent sources
3) to solve a unique or niche problem.

In general, you’d have to have all three to qualify in my book.

The first element of mashups are the integration technologies they use. These integration technologies create a “web as platform” architecture, allowing the mashup developer to integrate his software on top of the world class infrastructures provided by Amazon or AOL, simply, easily and safely. The most common technologies used for mashups include Web services calls, which either come as a SOAP or REST flavors, AJAX, Javascript and Ruby. The primary advantage of all of these technologies is that they are open source, have tremendous developer support and are fairly reliable, scalable and easy to learn and use. In fact, I personally believe that it was the development of these technologies to enable the quick development of responsive, data driven web sites that originally drove the mashup architecture, approach and culture.

The implication of this first part is that applications built with traditional programming models using C++ or Java don’t really count as mashups. C++ and Java are wonderful languages, and I make no prediction of their demise. But, they fail in two counts in our mashup test. First, both C++ and Java applications imply a platform below them that looks like a computer, not a network. Applications written in Java have a wonderfully large (largely wonderful) set of Java APIs that provide services on any computer on which your computer runs. C++ provides the ability to write complex programs that take maximum advantage of the underlying hardware. Both are inherintly computer platform focused. Mashups use the Web as their platform. Secondly, C++ and Java are heavy weight languages, and require a certain level of education and ability as a programmer to use effectively. The vast majority of Web programmers see Java’s cousin (Javascript) as being a programming challenge. Mashups enable mass development of applications. The majority of computer professionals do not have the inclination or aptitude for heavy weight programing.

The second element of mashups is that they take content or services from more than one independent source. This is where the “mashup” word comes from. Mashups take things that might not go together, and puts them together in a valuable way. The classic mashup is the Chicago Crime Map, that took data from the Chicago Police Department and plotted it on Google Maps, so that you could see where the burglaries happened. The classic business mashups are companies like Expedia, Priceline or Sidestep, that takes the reservation feeds from all of the airlines, hotels and car rental places, and lets you search for the best price. (Or they send William Shatner.) The independent sources of data from each carrier are used to create “smart shopper” service for travelers. Sometimes mashups are valuable because of their entertainment value - sites such as “slut-o-meter” and “wheel of food” come to mind.

Of course, the implication is that applications that take their data or services from a single source don’t really count as mashups, and I think this is by-and-large true. I’m suspicious of vendors that claim to provide a mashup solution, for two reasons. First of all, there’s the obvious point that there’s a single source. The second point is that little voice in the back of my head that says the vendor doesn’t get it. Mashups are certainly an area where walled gardens simply can’t exist at any level.

Finally, the third element of mashups are that they serve some small niche or community of interest. This last element isn’t so much about technology, or even business model, but is a very practical matter. Mashup architecture is a light weight architecture: it is best suited for solving small problems simply. Thus, the problems it would naturally attack would be small, and the audiences that would best appreciate it tend to be small as well. That’s not making any statements towards value, as the smaller problems are still valuable to those that have them. In fact, some argue (and I would be one of them) that the more personal a problem is, the more valuable that solution to that problem is to the person who has it. The issue is these personal problems are more difficult from a business perspective to aggregate, and are therefore apparently less valuable to large vendors.

To conclude, beware anybody with a silver bullet. Mashups shine, but not of metal. There are plenty of places and times where it’s an inappropriate approach to delivering new applications. As an example, not every vehicle carries six passengers - there’s still a need for eighteen wheel trucks and public transportation busses. But, in our everyday life, most vehicles are small passenger vehicles - and in the future - most applications will be small, light and personal. In today’s networked environment, mashups have no peer in that department.

Technorati Tags: telco mashups, thomas howe

Posted by Thomas Howe @ 6:43 pm | Filed Under Lead Stories |

Comments