The 5 Most Common Mashup Mistakes
Mashups are a popular topic lately, in both IT and business circles. Gartner recently named them a ‘Top 10 IT Technology for 2009’. But if your organization is thinking about ‘getting mashy’, here are five common pitfalls that you can avoid with just a little education and forethought:
- The ‘Fall for the Buzz’ Mistake: Misunderstanding what a ‘mashup’ is. Everyone wants to be associated with the hot buzzword and mashups are hot. Unfortunately, ‘mashup’ is a term that has also been used by vendors in areas like business process management, enterprise service bus (ESB), business intelligence (BI), and portals. So focus on the goal: mashups let you address just-in-time information needs by consuming and combining bite-size chunks of data, they run in ‘Internet time’ (i.e. seconds), they are usually relatively code-free, and they must make it easy to share with others. And there are, of course, a number of good independent software vendors that specialize in mashups.
- The Self-Serve Mistake: Every few years we hear about tools that will turn users into developers. It ain’t true. Yes, users are becoming more technically savvy and self sufficient every day (we call them ‘Business User 2.0’). But we’ll need IT for a long time to come, acting it’s new role as ‘enabler’. In the case of mashups, IT will establish a secure, reliable, and robust mashup infrastructure through which end-users can get mashing. In non-technical terms, IT builds the mashup lab and the business gets to play mashup mad scientist without worrying about blowing up the building.
- The SOA Mistake: Assuming you need an SOA before you adopt mashups. Sure, mashups put a business face on SOA, so to speak. And it’s easier for you to create mashups if there are a lot of ‘mashable’ (i.e. SOA-based) data sources. But the best mashup software can instantly turn databases and applications into mashable services. So don’t wait for that 5-year SOA effort to be finished before you start the mashup rollout. Use mashups to help you define the optimal SOA.
- The Silo Mistake: Mashups that aren’t reusable fall into the same ‘silo’ trap as legacy software. Mashups are their best when a community of like-minded users are building upon each other’s work. As we’ve written in the past, this kind of network effect does not happen automatically. Your mashup solution must have some kind of infrastructure to encourage reuse, such as a mashup ‘hub’, also often referred to as a ‘repository’ or ‘registry’. You (and your mashup software) have gotta have one.
- The ”Oops” Mistake: Thinking about security as an afterthought. Mashups can be based on business-critical data from your ERP system, your SFA system, your CRM system, etc. And, once created, they are often sent to many destinations (think portals, iPhone, and spreadsheets). You don’t want to find out your data has been compromised just because you assumed some kind of security was in place, do you? Your mashup solution must let mashup creators choose who they share with and the permissions. And the entire continuum of mashup inputs to mashup destinations need to be incorporated into your mashup plan. In technical terms, you need mashups that include LDAP integration and single sign-on support so they play nicely in your secure enterprise.
Understanding these common pitfalls can help your first (and your 50th!) mashup efforts be successful. Ignoring them will likely lead to mashup misery. Now get mashing.
[Reposted from Fast Company.]



3 comments:
There is probably a lot to say and discuss based on this article.
To me mashups are more a modern ( web based ) way to enable user to come up with their own situational applications - and to make it easier for them to combine multiple data sources.
Regarding "security" I am not sure whether security needs to be built more into the underlying APIs rather than the mashups. In other words: I think mashups are great for "public" data which are supposed to be shared anyhow to everybody, but I wonder whether they are the right tool for more sensitive data where you would need more control who can access it and how to present it - also in terms of the "one version of the truth". A SOA infrastructure could help here and would be a pre-requisite to use mashups also for more sensitive data.
Hi Axel,
If we're dealing with enterprise data, which Chris is referring to, then you definitely need security built into your Mashup infrastructure. Mashup servers act as an intermediary between the user and the services. Since we are mashing SOA and non-SOA services that are internal and external, we can't rely on the service infrastructure to provide the overall security and governance.
John Crupi
http://blogs.jackbe.com
Alex,
I think you, John and I are pretty much in agreement on most things.
What I didn't get to in my original article is the omnipresent subtle differences that lie in the type/status of the organization we're implementing are mashups in.
Here's a few examples: Is the SOA 10% complete or 90% complete? Is there an SOA registry/repository? Does the organization's LDAP/Active Directory server support authentication only or can we add domain-specific authorization privileges to it? Will public or legacy data be on the list of 'mashables' as well?
I think the right approach for an organization would vary based on variables like these and might even vary over the lifecycle on the enterprise architecture.
Chris
p.s. Have you 'mashed' yet? If so, we'd love to hear how it went!
Post a Comment