We need a better definition for “mash-up”

Mash-up no longer seems to mean was we thought it meant. The term has been claimed by the analysts and platform vendors as short hand for the current collection of hot product features, and no longer represents the goals and benefits of those original mash-ups that drew our interest. If we want to avoid the hype, firmly tying mash-up to the benefits we saw in those first solutions, then we need to reclaim the term, basing its definition on the outcomes those first mash-up solutions delivered, rather than the (fairly) conventional means used to deliver them.

Definitions are a good thing, as they help keep us all on the same page and make conversations easier. However, what often starts our as a powerful concept—with a clear value proposition—is rapidly diluted as the original definition gets pulled in different directions.

Over time, the foundation of a term’s definition moves from the outcome it represents (and the benefits this outcome provides), taking rest on the means which the original outcome was delivered, driven by everyones’ desire to define what they are doing in relation to the current hot topic. Next, the people who consider it to be just a means, often start redefining the meaning to make it more inclusive, while continuing to claim the original benefits. We end up selling the new hype as either means or goals or any half-hearted solution in between – and missing the original outcome nearly completely

The original mash-ups were simple things. Pulling together data from two or more sources to create a new consolidated view. Think push-pins on a map. Previously I would have had to access these data sources separately—find, select, remember, find, select correlation, click. With the mash-up this multi-step, and multi-decision workflow is reduced to a single look, select, click. Many decisions became one, and I was no longer forced to remember intermediate steps or data. 

It was this elimination of unnecessary decisions that first attracted many of us to the idea of a mash-up. As TQMLEAN, et al tell us, unnecessary decisions are a source of errors. If we want to deliver high quality at a low cost (i.e. efficient and effective knowledge workers) then we need to eliminate these decisions. This helps us become more productive by spending a greater proportion of our time on the decisions that really matter, rather than on messy busy work. Fewer decisions also means fewer chances for mistakes.

Since those original mash-up solutions, our definition of mash-up evolved. Todays definitions are founded on the tools and techniques used to deliver a modern web-based GUI. These definitions focus on the technology standards, where the data is processed (client vs. server), standards and APIs, and even mention application architectures used. Rarely do they talk about the outcome delivered, or the benefits this brings.

There’s little difference, for example, between some mashups and a modern portal. We can debate the differences between aggregating data on the client vs. the server, but does it really matter if it doesn’t change the outcome, and the difference is invisible to the user? The same can be said for the use of standards, APIs used, user configuration options, differing solution architectures and so on.

The shift to a feature-function base definition has allowed the product vendors and analysts of seize control of our definition, and apply it to the next generation of products they would like us to buy. This has diluted the term to the point that it seems to cover much of what we’ve been doing for the last decade, and many of the benefits ascribed to the original mash-ups don’t apply to solutions which fit under this new, broader church.

Modern consumer home pages, such as iGoogle and NetVibes for example, do allow us to use desk and screen real estate more effectively–providing a small productivity boost–but they don’t address the root of the problem. Putting two gadgets on a page does little to fuse the data. The user is still required to scan the CRM and order management gadgets separately, fusing the data in their head.  Find, select, remember, find, select correlation, click rather than a single look, select, click.

The gadgets might be visually proximate, but we could do that with two browser windows. Or two green screens side-by-side. The user is still required to look at both, and establish the correlation themselves. The chair might not swivel as much as with old school portlets, but eyeballs still do, and we are still forcing the user to make unnecessary decisions about data correlation. They don’t deliver that eliminate unnecessary decisions outcome that first attracted us to mash-ups.

The gold standard we need to measure potential mash-ups against is the melding of data used to eliminate unnecessary decisions. This might something visual, like push-pins on a map or markup on an x-ray. Or it might cover tabular data, where different cells in the table are sourced from different back-end systems. (Single customer view generated at the user interface.) If we fuse the data, building new gadgets which pull data attributes and function into one consistent view, then we eliminate these decisions. We can even extend this to function, allowing the user to trigger a workflow or process that make sense in the view they are presented, but with no knowledge of what or where implements the workflow.

We need a definition for mash-ups is that captures this outcome. Something like:

A mash-up is a user interface, or user interface element, that melds data and function from multiple sources to create one single, seamless view of a topic, eliminating unnecessary decisions and actions.

This v0.1 definition provides a nice, terse, strong definition for mash-up which we can hang a number of concrete benefits from.

  • More productive knowledge workers. Our knowledge workers only spend time on the decisions that really matter, rather than on messy busy work, making them more productive.
  • More effective knowledge workers. Fewer decisions mean fewer chances for mistakes, reducing the cost of error recovery and rework resulting in more effective knowledge workers.

Posted via email from PEG @ Posterous

Posted under: Business-Technology, Enterprise 2.0

Tagged as: , , , , , , , , , , , , , , ,

5 comments

  • Nigel Walsh on 2009-11-26 at 8:09 am said:

    Peter, as a vendor in the mashup space – I guess I'm guilty already of stealing the term – don’t hold it against me just yet. . I do think one of the challenges here though is that like all of this, its subjective..

    Who is 'we'? To me it means one thing, to others it can translate differently. There was a comment recently I saw that mentioned Capgemini's New White paper on Enterprise Mashups. The chap said it was too 'Sales' focussed and didn't do anything around data. Looking closer at his profile, he was a BI & MI Analyst so I can understand his point in that specific context…

    Indeed, even the new EMML standard introduced by another Vendor and meant to be neutral, in my opinion does not encapsulate the full potential of Mashups – it really just focuses on data again… again, call me subjective…

    Re your point on next generation products to buy, I think most Mashup Vendors don't sell a specific Outcome, we provide the tools to empower a business to create a Mashup that is suitable to their specific business problem. Each of the solutions has its own merits, some focus on data, others bring in user process, some are aimed at IT, others try to enable the business users to create fit for purpose Mashups

    I like your definition, but isn’t this also focussing on the two outcomes you highlight? Both valid and have clear business benefit.

    The important part for me is we start with the user and their specific context and work down, as opposed to the plethora of applications and work up.

  • Peter Evans-Greenwood on 2009-11-26 at 4:26 pm said:

    I less hung up on my definition than on the definition needing to capture some sort of tangible outcome. The fact that a modern portal falls into most of the means driven definitions is a bit of a joke (and then we have a lot of hand wringing to explain how they really are different). If we are going to have a definition and ascribe business benefits to it, then it must capture the outcome that provides those benefits. Otherwise we're just promoting hype.

    I'm reminded of biology in the 1800s (thing Master & Commander). They really had no clue on how the animal kingdom worked, so their focus on was on a pieces-parts approach, classifying animals by how they look rather than the role they play. While this provided a rough outline of what animals were, our modern, DNA driven understanding is starting to rewrite a lot of the rules as we realise we got it wrong. Our understanding of mash-ups seems to be not far beyond the dark ages.

  • Peter Evans-Greenwood on 2009-11-26 at 9:26 pm said:

    I less hung up on my definition than on the definition needing to capture some sort of tangible outcome. The fact that a modern portal falls into most of the means driven definitions is a bit of a joke (and then we have a lot of hand wringing to explain how they really are different). If we are going to have a definition and ascribe business benefits to it, then it must capture the outcome that provides those benefits. Otherwise we're just promoting hype.

    I'm reminded of biology in the 1800s (thing Master & Commander). They really had no clue on how the animal kingdom worked, so their focus on was on a pieces-parts approach, classifying animals by how they look rather than the role they play. While this provided a rough outline of what animals were, our modern, DNA driven understanding is starting to rewrite a lot of the rules as we realise we got it wrong. Our understanding of mash-ups seems to be not far beyond the dark ages.

Leave a Reply

%d bloggers like this: