Analyst Looks at Mashups vs. SOBAs
Mashups need to get serious and take a lesson from SOBAs if they're to
succeed in the world of enterprises.
The Web 2.0 era has ushered in mashups, the practice of stitching together applications from a collection of existing -- and usually Web-based -- assets.
These days, one can hardly launch a browser without tripping over a passel of mashups like EarthAlbum, which slaps together content from photo-storage and mapping sites to create on-demand visual tours of the world.
Cool stuff, for sure. But it's an open question how the mashup concept can be applied to business-critical functions within enterprises, where the concerns go well beyond gee-whiz functionality to include questions of governance, security and availability.
Analyst Jason Bloomberg of ZapThink LLC, a consulting group focused on service-oriented architecture (SOA), is set to deliver a talk on mashup-style development and the enterprise at the upcoming SOA World Conference & Expo, scheduled for June 25-27 in New York.
Bloomberg draws a line between consumer-oriented mashups and service-oriented business applications (SOBAs), and argues that while mashup principles have their place within enterprises, serious challenges await any effort to implement them.
What's the difference between a SOBA and a mashup?
They're sort of coming from different worlds. A SOBA is essentially a composite application composed of business processes. It comes from the SOA world. A mashup is essentially a collaborative app within a rich Internet application (RIA) environment.
What challenges do corporate dev shops face in implementing mashups?
The first is loose coupling. If you're mashing up services and something happens, your mashup's going to break. It's one thing to say my pizza-Google map mashup broke, [because] no one cares. But if it's your call center app, that's a different story. You need that loose coupling to support services throughout their full lifecycle.
The other is governance. Mashups give users the capabilities that previously have been reserved for IT. But if you give them the capability without guidelines on what to do, they're just going to go off half-cocked.
You have to have that governance framework in place so people who are doing the mashups can only follow the rules. Without SOA, mashups are toys. Without governance, mashups are dangerous.
Ideally, who within an enterprise should be creating mashups? A developer? An IT administrator?
If you have a mashup tool, it's not that the tool is for one kind of person, but rather that depending on the policy it gives different capabilities to different people. A call center rep may not have any capabilities, but an IT person would have a much broader set. For the most part, even the best mashup tools are still for technical people. Over time it'll be as easy to use a mashup tool as Microsoft Excel. We're just not there yet.
Chris Kanaracus is the news editor for Redmond Developer News.