Tag Archives: mash-ups

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

What are the benefits of a mash-up?

The original mash-ups were simple things. Solutions like the Chicago Crime and AlertMap pulled together data from two or more sources (maps and crime databases, in the case of Chicago Crime) to create one single view. Previously I would have had to access these data sources separately–find, select, remember, find, correlate, 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 data.

TQM, LEAN, et al tell us that 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 brings a few immediate benefits:

  • More productive knowledge workers. Our knowledge workers only spend time on the decisions that really matter, rather than on messy busy work.
  • More effective knowledge workers. Fewer decisions mean fewer chances for mistakes.
If we were to use mash-ups in this way to simplify key, call centre processes (for example) then we can can translate these two points direct into business benefits:
  • Reduced staff on-boarding costs, cutting training time, and reducing time to competency by providing a simply and more direct workflow, one which leads the call centre operator through the workflow.
  • Reduce call servicing costs, including reduced escalations and improved first call resolution by avoiding mistakes and and ensuing that the operator has all the information required to solve the customer’s problem on hand.
  • Improved staff retention, by allowing them to focus on the customer engagement, rather than soul destroying swivel chair integration.

With a typical call centre agent using six applications per call, this represents a drastic simplification of the call centre work environment.

A third benefit is the decoupling a mash-up creates between presentation and back-end applications. As all user interaction is mediated by the mash-up, there is not direct connection between the data and function provided by a single application, and the work surface the knowledge worker interacts with. This enables us to evolve the UI and back-end separately, allowing us to keep the user interface in sync with business demands while continuing to pursue a separate, and longer cycle consolidation effort to consolidate backend systems to reduce operational costs.

It’s easy to extrapolate these (potential) benefits to other solutions. My favourite is human services, where providing a case worker with the right information at the right time, and removing unnecessary distractions, will result in a material difference in the quality of life for the people under their care. However, these benefits can easily be applied to any high value knowledge work processes, such as logistics exception manager, utility field worker, sales personnel, and so on.

Posted via email from PEG @ Posterous

You keep using that word. I do not think it means what you think it means.

Inigo Montoya
Inigo Montoya

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up.]
Vizzini: HE DIDN’T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what you think it means.

The Princess Bride

We keep using these words, but they don’t seem to have any meaning anymore.

Agile. It started with agile software, and seems to have spread like a virus to (agile) testing, (agile) architecture etc. At some stage we confused two ideas: agile delivery and agile outcome. One does not imply the other; while your process might be agile, being able to redeploy the team quickly does not guarantee an agile result for the business. You can make your architecture/development/testing team as agile as you like, but if the solution they are working on is a giant furball, then business agility will elude you. And by getting this wrong in the eyes of the business, we’ve made the term next to meaningless.

Architect(ure). Back when I was a lad, every geek wanted to be a grow up to be a systems analyst. None of us really knew what a system analyst did, but the title sounded good, they seemed to be senior and the pay was ok. Some time in the last few years, architect (and architecture) have replaced system analyst in the minds of aspiring software engineers. The minute we reach something like team lead we start calling ourselves “architect”. This puts software engineering in the strange position of having a surplus of architects, but very little real architecture.

Chief Technology Officer. Full disclosure, I carry the CTO title. I prefer to use the acronym rather than spell it out–to avoid confusion. With technology playing an increasingly important role in business, using technology well (or not) can have a disproportionate impact on a company’s performance. The idea behind a CTO is a good one: someone to advise how to leverage technology at a senior level. Though most CTO roles seem to be something else: head of development (nee VP Engineering) product management (Dir. Product Management), or just “big solution architect”. Using one title in so many different ways means that the title has little meaning to the business. I prefer to use the acronym, focus on helping the business solve problems, and let them make up their own mind on what it means.

Innovation. We have big innovations, and small. Industry defining disruptive innovations, and incremental innovation. There’s whole ontologies of innovation. We’re told to innovate our way out of recessions, and to innovate to remain competitive in bull markets. There’s a surplus of innovation activities, yet very little seems to happen. All this thunder without rain makes me yearn for more obliquity. Innovation should imply doing something useful, making a difference, rather than being reduced to a label for an ever growing consulting industry and a lot of talk.

Mash-up. From that first push-pins on a map solution, fusing data from a range of sources (GIS, reviews, yellow pages …), the mash-up concept seems to be growing to include an UI concept that we want to generate buzz around. iGoogle and NetVibes as mash-ups? Aren’t these just a SaaS version of the portals of old?

Synergy. Many things in the business world are done to release “synergies”. Mergers and acquisitions are driven by the quest for synergies. PowerPoint business plans are often considered incomplete unless they line up A and B, proudly announcing that synergies will make it all worthwhile. Why then, do promised synergies so rarely eventuate? We seem to use the term as a vague aspirational statement, rather than a call to action.

More terms as I find time. Send in your own and I’ll add them to the list.

Update: The Economist points out where synergy went wrong.

Update: Added “mash-up” after commenting on Enterprise Mash-Ups in Transition.

Update: You can find my attempt at a clearer and more consistent definition of mash-up over at We need a better definition for “mash-up”.

Posted via email from PEG

Balancing our two masters

We seem to be torn between two masters. On one hand we’re driven to renew our IT estate, consolidating solutions to deliver long term efficiency and cost savings. On the other hand, the business wants us to deliver new, end user functionality (new consumer kiosks, workforce automation and operational excellence solutions …) to support tactical needs. But how do we balance these conflicting demands, when our vertically integrated solutions tightly bind user interaction to the backend business systems and their multi-year life-cycle? We need to decouple the two, breaking the strong connection between business system and user interface. This will enable us to evolve them separately, delivering long term savings while meeting short term needs.

Business software’s proud history is the story of managing the things we know. From the first tabulation systems through enterprise applications to modern SaaS solutions, the majority of our efforts have been focused data: capturing or manufacturing facts, and pumping them around the enterprise.

We’ve become so adept at delivering these IT assets into the business, that most companies’ IT estates a populated with an overabundance of solutions. Many good solutions, some no so good, and many redundant or overlapping. Gardening our IT estate has become a major preoccupation, as we work to simplify and streamline our collection of applications to deliver cost savings and operational improvements. These efforts are often significant undertakings, with numbers like “5 years” and “$50 million” not uncommon.

While we’ve become quite sophisticated at delivering modular business functionality (via methods such as SOA), our approach to supporting users is still dominated by a focus on isolated solutions. Most user interfaces are slapped on as nearly an after thought, providing stakeholders with a means to interact with the vast, data processing monsters we create. Tightly coupled to the business system (or systems) they are deployed with, these user interfaces are restricted to evolving at a similar pace.

Business has changed while we’ve been honing our application development skills. What used to take years, now takes months, if not weeks. What used to make sense now seems confusing. Business is often left waiting while we catch up, working to improve our IT estate to the point that we can support their demands for new consumer kiosks, solutions to support operational excellence, and so on.

What was one problem has now become two. We solved the first order challenge of managing the vast volumes of data an enterprise contains, only to unearth a second challenge: delivering the right information, at the right time, to users so that they can make the best possible decision. Tying user interaction to the back end business systems forces our solutions for these two problems to evolve at a similar pace. If we break this connection, we can evolve users interfaces at a more rapid pace. A pace more in line with business demand.

We’ve been chipping away at this second problem for a quite a while. Our first green screen and client-server solutions were over taken from portals, which promised to solve the problem of swivel-chair integration. However, portals seem to be have been defeated by browser tabs. While these allowed us to bring together the screens from a collection of applications, providing a productivity boost by reducing the number of interfaces a user interacted with, it didn’t break the user interfaces explicit dependancy on the back end business systems.

We need to create a modular approach to composing new, task focused user interfaces, doing to user interfaces what SOA has done for back-end business functionality. The view users see should be focused on supporting the decision they are making. Data and function sourced from multiple back-end systems, broken into reusable modules and mashed together, creating an enterprise mash-up. A mashup spanning multiple screens to fuse both data and process.

Some users will find little need an enterprise mash-up—typically users who spend the vast majority of their time working within a single application. Others, who work between applications, will see a dramatic benefit. These users typically include the knowledge rich workers who drive the majority of value in a modern enterprise. These users are the logistics exception managers, who can make the difference between a “best of breed” supply chain and a category leading one. They are the call centre operators, whose focus should be on solving the caller’s problem, and not worrying about which backend system might have the data they need. Or they could be field personnel (sales, repairs …), working between a range of systems as they engage with you customer’s or repair your infrastructure.

By reducing the number of ancillary decisions required, and thereby reducing the number of mistakes made, enterprise mash-ups make knowledge workers more effective. By reducing the need to manually synchronise applications, copying data between them, we make them more efficient.

But more importantly, enterprise mash-ups enable us to decouple development of user interfaces from the evolution of the backend systems. This enables us to evolve the two at different rates, delivering long term savings while meeting short term need, and mitigating one of the biggest risks confronting IT departments today: the risk of becoming irrelevant to the business.

Extreme Competition

I’ve uploaded another presentation to SlideShare. (Still trying to work through the backlog.) This is something that I had been doing for banks and insurance companies as part of their “thought leadership” sessions.

A new company enters the market in late 2008, LGM Wealth Management, who have found a new way of spinning existing solutions and technologies to provide it with capabilities an order of magnitude better than anyone else.

  • Time to Revenue < 5 days
  • Cost to Serve < ½ industry average
  • New Product Introduction < 5 days
  • Infinite customization

How do you react?