Defining Mashups

[Cross-posted from]

Over the last year, the term mashup has become extremely popular not only in the consumer software space, but also in enterprise software. It has been a little more than a year since I joined JackBe as VP of Engineering responsible for executing our vision. Over this time, I and our team at JackBe has been busy creating our enterprise mashup platform, which is a unique innovative offering in enterprise software today, by combining the benefits of RIA technologies such as Ajax/RIA, Web Services, Service Oriented Architecture and Mashups.

At the internal technology briefing last week, I and my team presented and demonstrated the features of Presto, JackBe’s enterprise mashup family of products, to 25 developers and consultants. One of the important areas of discussion was around what we mean by a mashup and how the term ‘mashup’ has evolved over the last year to mean almost anything. For example, the following is the definition of the term mashup on Wikipedia:

A mashup is a website or application that combines content from more than one source into an integrated experience.

The problem with this definition from my perspective is that it allows you to practically label anything as a mashup, including a portal application, composite application, and what have you that brings disparate content onto a single web page.

I don’t think I want to disagree with this or any other definition of a mashup floating around in the industry. However, I feel that all the existing definitions and explanations are lacking something so important about the real intent of these mashups. This was also apparent at the discussion a few weeks ago at the IBM Mashup Ecosystem Summit. So, now I feel compelled to offer you what we at JackBe mean by a mashup:

A mashup is a shareable software block created by a user, encapsulating ad-hoc user driven processing of disparate data sources, delivered with a user focused view.

Allow me to elaborate further using the following characteristics:

  1. Mashups are made up of user driven micro-orchestrations. In other words, when I access some data or service, I am performing small operations on the way data is computed and rendered in a very informal and iterative manner. For example, consider how one uses a spreadsheet which is a great example of a canvas where mashups happen in the enterprise when a user pulls in data from different sources, combines, sorts, computes, filters and visualizes by iteratively processing it until he gets the desired results. If you really think about it, what the user is doing is really orchestrating getting data from different sources and processing using one or more operations to yield an integrated view of the data.
  2. Mashups are user focussed, i.e. they are primarily created by the user for the user. They are not the product of some developer or IT guy writing a lot of code. However, current examples of mashups that we see are primarily developer oriented, it is just the beginning. The real value of mashups comes when we enable and empower our end users to perform these mashups the way they want to do it without having to call and rely on IT needs.
  3. Mashups are ad-hoc creations and are very situational based on users immediate short term needs. They are designed by the user to meet a specific need. These mashups have a very short life span varying from hours to days. This is the reason that the users cannot wait and demand IT to create and deliver these mashups.
  4. Mashups can be visual and non-visual. The most common kind of mashup that is out there is probably something that overlays some information on some kind of a map. However, there is more to mashups than just displaying pins on a map. I can mashup disparate data to create an integrated data view. I can mashup processes to create a new process. I can mashup domain models of different application domains to create a new application domain model.
  5. And finally, mashups can be performed on the client side and on the server side. However, I think the best value of a mashup is when we combine both client side and server side mashup functions since we can defer heavy lifting to the server and build intelligent clients that can enhance, complement and focus on user experience.

Before I conclude, I would like to emphasize a few points.

  1. Whether we do visual or non-visual, client-side or server-side, mashups must be user driven and user focussed.
  2. Just because mashups are user driven and user focussed does not mean that we no longer need IT. IT is still a critical part of the whole mashup infrastructure in an enterprise. However, instead of the users going to IT for every little thing they need which can be transient, situational and ad-hoc, they should be able to accomplish what they need without having to rely on traditional IT and experienced programmers to build what they need. For example, imagine what would happen if Microsoft Excel users needed IT help to write a macro or to create a chart from a table of data they put together. Mashups in the enterprise must address these kind of needs of enterprise users accessing disparate data and services to create and share new information in the Enterprise Web 2.0 world.

In my next blog entry, I will discuss more about our work in creating our comprehensive enterprise mashup platform that encompasses the above characteristics. It finally feels great to be able to talk about what we have been obsessively building over the past year!

What do you think? I am really interested to hear other opinions and thoughts around this.


Published by


Cofounder & CTO @