How can an enterprise architect convince the business side of the organization to invest budget dollars on using mashups?
Recently, I was preparing a conference presentation on “mashups as a transformative technology”. In my outline, I focused on four distinct approaches I have tried to help mashups gain traction where I work. My analysis was that none of these techniques was particularly successful. As Anthony Bradley from Gartner Research famously stated, “You can’t build a business case for enterprise mashups, [but] you can build specific mashup-centric business cases”.
I agree with Anthony. I’ve struggled with this problem for a long time now. I’ve followed his advice and created specific mashup-powered solutions for many problems. Finally, I formed a conclusion that I’d like to tack on to the end of his statement: No matter how many mashup-specific business cases you create, you still can’t justify mashups as a general discipline for the enterprise.
With mashups, each solution you create can be so unique that the general practice (let alone any proprietary vendor tools you might have used) doesn’t get any credit.
Since mashups aren’t getting the recognition they deserve, I make the following proposal: Let’s start branding them. To this end, I am announcing a series of “Made with Mashups” logos that I am releasing under the Creative Commons license:
You can download the complete set (and source) from http://madewithmashups.com.
This is a vendor neutral, non-application-specific image. It doesn’t matter how the mashup was actually created. The purpose of this branding is to take all of the disparate solutions we have been building and give them something in common. Whether you link the logo to madewithmashups or some internal wiki page you create, when you use the MwM image you are saying, “This solution was built in an innovative new way”. Deliver enough good products with this logo, and users might actually start asking you to build stuff “the same way you made those other apps with the crazy M at the bottom of the page”.
Lest we forget, many of the technologies we take for granted today raised their awareness by taking a similar approach. Can you believe there was a time when people were unfamiliar with Java or Linux?
Do we need to worry about interoperability and open standards for mashup tools? Absolutely. But that’s putting the cart before the horse. Demand isn’t high enough yet to shift vendors’ focus away from building market share for their individual products. If one or two vendors come to dominate the space, then the discipline and tooling will become inseparable.
We can build a general business case for Mashups. But it’s not going to come from showcasing one or two good ideas. Mashups are too general for that to work. We need an overwhelming base of solutions. The “Made with Mashups” logo is a first step towards putting that collection together.
Dig Deeper on Application integration architecture
Related Q&A from Michael Ogrinz
There are scenarios where HTML5 is better than native applications. Expert Michael Ogrinz discusses best uses for each. Continue Reading
Mike Ogrinz says risk-taking is part of software innovation. There should be 'potential for failure,' a key ingredient to innovation. Continue Reading
Before building out a new enterprise portal application, you should probably examine existing systems to make sure they don't need to be ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.