Our key point of difference seems to be what “fusion” is.

Putting two gadgets on a page does little to fuse the data. The user is still required to scan the CRM and order management portlets separately, fusing the data in their head. The portlets 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 with portlets, but their eyeballs still do, and we are still forcing the user to make unnecessary decisions about data correlation.

TQM, LEAN, et al tell us that these unnecessary decisions are the 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 them. Portals 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.

If we fuse the data, building new portlets which pull data attributes and function into one consistent view, then we eliminate these decisions. The easiest solutions to comprehend are the many location based services which tie together a range of data sources into one consistent view. You look and touch; rather than look, remember the address, type it in, hit search, and (too often) realise you got it wrong.

The tabular version of this is to source the data from multiple backend systems, attribute-by-attribute. The user doesn’t see CRM, order management and inventory management; they’re provided with a single portlet showing “where the box is” with each cell in the table (potentially) sourced from a different system. All correlation/mapping is done in the software, not the wetware, letting the user focus on the decisions that really matter.

The example in the slide deck does this in two levels. A semantic web-like solution (I’m showing my AI background now) in the middle tier maps gross backend data sets, and integrates them with user generated content, such as tags. Mashup widgets then present this data, fused with more external data, to the user. The most obvious example is Homer’s head, pulling together separate xray and diagnosis data. The whole lot is presented via a portal, (iGoogle possibly, as there is no reason to own the portal in many cases), but could be delivered over multiple channels (portal, voice, iPhone app …) if need be.

My position on mash-ups is that they need to be focused on eliminating unnecessary decisions. This provides a nice, strong definition for mash-up which we can hang a number of concrete benefits off, and distinguishes them from the data-silos that came before.

If we use a proximate data argument, then “mash-up” could include any portal or dashboard technology created in the last 20 years, and dilutes the potential benefits we can ascribe to mash-ups.

The new generation of portals/dashboards (iGoogle et al) are useful tools. However, they don’t address this core challenge of eliminating unnecessary decisions, and are going to become less relevant for a lot of knowledge workers anyway, as we increasingly move to a mobile and multi-channel world (but that’s a separate post).

r.

PEG

You talk about data fusion. Data fusion has been around since, well, data. Data fusion (depending how you define fusion) may or may not be part of a mashup. Tell me what the major difference is between dropping gadgets on a browser page and dropping location data points on a map. Both are integrating information based on proximity in a visual paradigm. Why are you saying one is a mashup and not the other?

The US intelligence community is using mashup dashboards (call them personal analyst portals if you want) to visualize data from multiple sources in one place. Major benefits they say they gain is reduced swivel chair integraton and visualization flexibility. Don’t downplay the importance of gadgets and their role in mashups. If you restrict mashups to some definition that requires API integration then you are taking too technical a viewpoint and, of course, are then limiting mashups to developers.

These new generation of portal tools provide some limited benefits, mainly from putting all your stuff on one screen, but they don’t provide the benefits I listed above. They don’t reduce swivel chair integration as users are still required to cut and paste data between portlets. Nor do they improve user effectiveness, as we haven’t cleaned up the workflow to eliminate unnecessary decisions. And the UI elements (portlets) still (typically) map directly to the backend applications, so we don’t decouple UI from IT estate.

If we want to define “mash-up” as any composed UI, then we can easily claim that we have user created mash-ups, and we’ve had them for some time. What’s the point though? Tools like iGoogle are nice jumping off points, but they’re SaaS delivered portals rather than the Enterprise 2.0 mash-ups we’ve been promised. This is not significantly different to the portals and dashboards we’ve had for over a decade.

Mash-ups need to do something meaningful by fusing data sources. Think back to the “push-pins on a map” mashups, fusing a range of data sources (GIS, reviews, yellow pages …) to create one integrated message. Otherwise we’ve coined yet-another term with no meaning.

Creating this sort of view is beyond most users skills or interests, and will stay that way. We can develop tools to make mash-ups easier to create, but creating them will always be something like programming. The resulting mash-up could be delivered to you as a portlet via something like iGoogle, but that doesn’t make iGoogle a mashup: don’t confuse message with messenger. While some of the vendors have users choosing which portlets (or mashlets, as they call them) to use, constructing these mash-up portlets is still programming.

I have a preso on mash-ups in insurance which you might want to check out to see where I’m coming from.

r.

PEG