Back in 2007 and early 2008 I anticipated a rapid rate of enterprise mashup adoption. Just about everyone, including me was talking about enterprise mashups as a new paradigm for end user computing where business users would rapidly assemble and reassemble applications in a highly dynamic fashion. Users can “create applications as fast as the situation changes” was one of the lines I used. I talked about The MacGyver Principle and Tom Cruise’s character in the movie Minority Report. This was a truly revolutionary vision and the tremendous power of mashups to drive change.
Then the economic downturn hit us hard. Many enterprises curtailed investment in new systems to instead focus on how to get the most out of their current IT investments. The financial industry, an early adopter of mashups was obviously hit the hardest. Gartner client interest in mashups waned slightly but I was anticipating a significant escalation prior to the downturn. You may have noticed that enterprise mashups is not on Gartner’s top ten technologies to watch anymore.
Then a shift in the need began. Instead of asking about end user empowerment, clients began inquiring about how to reduce integration costs with mashups. Some organizations were trying to use mashups to clear out their application integration backlog more quickly and at less cost. Others were facing new integration challenges due to mostly unexpected mergers and acquisitions.
This new use case is now rippling through the enterprise mashup technology sector. Many mashup vendors were direct selling an end user based solution to business unit leaders. Now the main buyer is in the IT shop. several mashup vendors are now adapting their value proposition and marketing messaging to this new audience. Additionally, there is a movement to an indirect sales model that has mashup players working hard to establish relationships with systems integrators. All this takes time to build traction.
I still believe that end user empowerment is the nirvana for enterprise mashups. It seems we will just need to wait a while before the “MacGyver principle of applications” is a mainstream reality. In the meantime we will just have to settle for a better way to address some application integration challenges 🙂
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
9 Comments
Anthony
Agree with shift towards integration you are mentioning. In our experience, success in this environment requires two key capabilities:
(1) Quickly and easily make a wide range of existing technologies \mashable\ – from mainframes to thick client applications and web applications as web services
(2) Capacity to deliver mashups as \composite applications\ that integrate not only data but also process and UI to ensure right return on investment
Given these capabilities, enterprise mashups become an essential tool for IT to address familiar integration problems in a new, quicker and more cost effective way. For example:
– Linking internal and new SAAS / cloud solutions
– Integrating packaged applications such as CRM to internal applications
– Simplifying and accelerating migration of legacy applications to new packaged applications
– Leveraging legacy applications into new, simplified composite applications
More details and examples of these can be found at http://bit.ly/chCgJ.
These issues do not only concern IT but also business unit leaders in that they greatly reduce the efficiency of their teams. In today’s environment, many businesses are looking for way to deliver a step up in people productivity with short and low risks projects: enterprise mashups are perfectly suited to that.
This type of pragmatic integrations will naturally create a pool of reusable mashable components if done with the right technology. Once created (and paid for) thanks to these projects, these components will make it easier for end users to create their own mashups in a safe way, with the buy in from IT. So the nirvana of end user empowerment is perhaps not as distant after all!
The dream of having users create their own applications via mash-ups is like the dream of SMEs directly encoding rules or business processes: an aspiration rather than an achievable goal. While we can provide solutions which are more understandable and flexible (which is a good thing), the rigor required to define a working GUI/process/rule is not something most users are comfortable with or interested in.
The business case for mash-ups rests on more prosaic arguments than end user developed solutions.
More effective users. Mash-ups let us reduce the number of errors by reducing the number of decisions a user needs to make as they complete a task.
More efficent users. Mash-ups eliminate swivel-chair integration, making users more productive.
Risk mitigation. Mash-ups let us decouple user interfaces from backend applications, allowing each to evolve at their own pace.
r.
PEG
Thousands if not hundreds of thousands of end users already assemble their own applications using basic consumer side mashup environments like iGoogle, NetVibes and PageFlakes. I am one of them. Several of the enterprise mashup players also have end users building mashups. It is achievable. It has been achieved. The question is when it becomes an enterprise mainstream practice. For that we will need to wait a few years.
However, I certainly agree with your list of mashup benefits.
Calling iGoogle, NetVibes and PageFlakes mash-ups is drawing a very long bow. They’re user configured portals, which we’ve had for quite a while, not the data fusing mash-ups which started the craze.
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
Looks like we disagree on the definition of a mashup. IME, a mashup is a new application that is assembled, using web technologies, from existing systems capabilities. I have built several entirely new mashup applications using iGoogle for my research as well as personal activities. I have been using enterprise portals for years and years and they never offered capabilities like iGoogle. Granted they are basic mashups but they are mashups none the less. You can call iGoogle a personal portal if you like but those capabilities have certainly not been around for a decade. They absolutely reduce swivel chair integration in that I don’t have to go to each source site (the www equivalent of swivel chair).
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.
I looked at your presentation which seems to prove my point. The def you quote is similar to mine (it says nothing of data fusion or API integration). The screen example you use could very well be assembled from predefined gadgets that the user places on the page. iGoogle and the like are not enterprise mashups, they are consumer side mashups, but they demonstrate the power of assembling an entirely new application from a repository of exisitng parts. Enterprises need enterprise robust versions of iGoogle if they expect end user mashups. Some have built them but it isn’t yet mainstream.
At DreamFace we extend the iGoogle, Netvibes model to provide user defined interactions between widgets. This allows for integration of existing applications and new applications or data sources to be composed into real and complex new applications with screens of interacting widgets and application workflow (master / detail, business rules, etc..). We are seeing an increased need for this kind of application integration / aggregation. For a long time the industry has defined mashups as some kind of quick and dirty throw away application. We don’t see it that way. We think that widgets offer the building blocks to create real, complex, interactive, modular applications that are built for change from existing apps, web services, widgets, technologies, etc..
The definition quoted is the standard industry one at the time (for what it’s worth) used as a jumping off point, rather than a definitive statement on what a mashup is or could be.
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