Enterprise Software

Mashups: No SOA required, but keep IT in the loop

Everyone is excited about the possibility that business end users will be able to design mashups for their own purposes without having to wait for IT to build the interface. Check out the five common mistakes to avoid with mashups.

This is a guest post from Joe McKendrick of TechRepublic's sister site ZDNet. You can follow Joe on his ZDNet blog Service Oriented, or subscribe to the RSS feed.

No doubt about it, mashups are the new breed of composite application that sits in front of SOAs. The vision that has gotten everybody excited is the possibility that business end-users would be able to design their own mashups for their own purposes, without having to wait for IT to build the interface.

It's a nice vision, and Jackbe's Chris Warner, writing in Fast Company, agrees that you don't need a big, honking service oriented architecture with some grandiose five-year roadmap. When it comes to mashups, to paraphrase Nike, just do it. However, Chris does caution that IT establish the initial framework to prevent business users from "blowing up the building."

I would venture to add that while it may not be happening today, mashups should be a part of the SOA evolution. A budding SOA governance approach may ultimately be the best framework in which to manage and encourage mashup development and operation. Mashups may even drive the look and feel of SOA going forward. You know, more business friendly, less IT-ish.

Chris outlines "the five common mistakes to avoid" with mashups:

1) Don't fall for the "buzz." All the vendors now say they offer mashups. True mashups have nothing to do with any vendor. They are just-in-time, and are built on Internet standards. 2) Keep IT in the loop. IT needs to "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." 3) You don't need SOA to adopt mashups. Mashups can be done now, without waiting for SOA to come along. 4) Encourage mashup reuse. Chris notes that "this kind of network effect does not happen automatically. Mashup reuse requires some kind of infrastructure to encourage reuse, such as a mashup 'hub', also often referred to as a 'repository' or 'registry'." Again, the evolving SOA governance structure may be the way to handle this. 5) Security, security, security. This has been a big issue in the SOA space. Since mashups may be tapping into sensitive or mission-critical data, security shouldn't be an afterthought.
1 comments
Justin James
Justin James

... then why is it that they all simply seem to merge a dataset with Google Maps? So far, all I have seen is that Google Maps is a useful API. Until I see some mashups that are truly useful, and don't use Google Maps, I'll be calling "mashups" pure "hype". The "mashup" movement has been around for a few years, that's more than enough to show some value if there really is some. J.Ja

Editor's Picks