What is a mashup and why I should develop one?

Today is very common to hear about ‘Web 2.0' and around this, some other terms, such as ‘Mashups'. And here comes the questions:

-          What is a mashup?

-          Which are the main components of a mashup?

-          When is it useful to develop a mashup?

-          What are the characteristics of a mashup?

-          What is next?

-          ...and others that may arise..

First of all, this is a ‘young' term, introduced within this ‘Web 2.0' era. Secondly, I found a very clear and practical introduction to the topic here by Larry Clarkin and Josh Holmos. I strongly recommend reading it.

Based on the concepts and some transcriptions of that article and others (see References below), I will try to answer the above questions.

1.       What is a mashup?

Some places refer to mashups as web applications that combines data from more than one source, hiding this behind a simple unified graphical interface. Despite for me this is true, I prefer another definition which widens the scope, referring to a mashup as a technique, as an architectural style for building applications that combine data from multiple sources to create an integrated and improved experience to the user.

Some examples of mashups are those that integrate address information with Google Maps or Virtual Earth to generate an integrated experience, applications that integrate contacts from multiple sources like Plaxo, applications that integrates online with Wikipedia, etc. Here is a site that in theory shows the best mashups on the web: http://mashupawards.com/         

It is common to associate mashups with S+S (Software plus Services) as typically they consume ‘cloud services' and also with Rich Internet Applications (RIAs) as they can provide more visual richness.

It is important to differentiate a mashup from simple embedding data from another site. For instance, if I have a site that allows to see a video in YouTube I do not have a mashup, that is simple embedding. Mashups are intended to add value to the final user, processing information consumed by any API/WebService and displaying it in an integrated experience.

2.        Which are the main components of a mashup?

Here is the architecture of a typical mashup application:

The main components, categorized and summarized are:

o   Data Sources - data sources are the core elements of any mashup and represent the data being aggregated. The source could be a database, Webservice, API, RSS, etc.

o   Platform services - depicts special kind of services that go beyond the typical request/response. For instance, Virtual Earth and the majority of the ‘cloud services' that are starting to emerge [i.e. windows live services]. Microsoft's Biztalk Services, an Internet Service Bus is another example, even though it is a technology even more immature than the former.

o   Mashup Application - it is the application that combines the data from the different sources and in some cases, applies some lightweight business logic. Usually it is a web application [ASP.net, PHP] or a RIA [Rich Internet Application - Silverlight, Flash].

3.       When is it useful to develop a mashup?

A great way of understanding the benefits of a mashup in an enterprise environment is with an example. Let's imagine that you are an application architect for a call center system that receives calls about warranty and parts service. Using the phone number of the caller, we could display the records for that user, including a purchase history. This interesting application has already been implemented today in most call centers. But what if, in addition to looking up the customer information, we plotted the phone number on a map using a publicly available service and also displayed a list of local service centers or parts suppliers for our products overlaid on the map? With this data in hand, we might be able to answer the customer's questions in seconds. What if we also looked up the current weather conditions in that area or other information of interest for the customer?..

Combining data from public services (such as weather and news) with internal sources of data (a customer service alerts blog and a database of service locations), this application combines the mashup elements with the accessibility of a portal. See next sample picture:

Realizing Return on Investment (ROI) is a common concern for Service-Oriented Architecture (SOA) deployments. Many organizations find it difficult to justify the upfront investment for creating services for different functionality when it would be easier to create a single application. Enterprise mashups are a great example of how an investment in SOA can provide great value.

4.       What are the characteristics of a mashup?

We could infer the following outstanding characteristics of mashups, based on the concepts mentioned above:

o   A mashup is focused on adding value, putting a tremendous amount of ready information at the fingertips of the final user.

o   Information + User experience should be efficiently combined, using technologies such as RIAs.

o   A mashup is contextual to the task at hand.

o   It prioritizes the information in the order in which is most likely to be useful. You have to know who you are talking to, what products they have registered, what the top service items are for those products, and then start trying to answer questions that they may have such as where the local service centers are for the customer's location.

o   Developing a mashup must be measured in hours or days. That is a big difference with building a complete application, for instance. The quick turnaround time for mashups can change the way that IT departments interact with the users in their organizations.

o   Generally, it is read-only.

o   Mashups are agile views into the data that they present. They are not an all-powerful editing surface capable of editing any and all data thrown at them. If someone wants to edit that data, they should go back to the application that created the data to do the editing.

o   A timestamp may be important for improving the clarity and usefulness of the mashed data.

My suggestion and maybe the key factor of success of a mashup is applying the Keep It Simple paradigm. A mashup is not intended to solve complex enterprise problems. I suggest you focus on making your mashup do only one thing and do that thing well. For large problems, go for a traditional project.

5.       What is next?

We can wide the vision and think of mash-ups as a new paradigm, a new way of building and delivering applications. In that way, if we provide tools that allow other users than only developers to build mash-ups we could be reaching a point where the customer itself builds his/her own mash-up.

For instance, dragging and dropping sources of data, combining them in a layout and visual representation, generating a RIA which could be easily delivered.

Best of all, we are not so far away from this new paradigm if we explore tools like Microsoft Popfly and Yahoo Pipes.

References:

http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

http://msdn.microsoft.com/en-us/library/bb906060.aspx