Addressing the challenges of enterprise mashups

I’m finally getting around to thinking about Dion’s post on the challenges facing enterprise mashups.

As usual, he does a terrific job listing the challenges, but what I thought was lacking was some measure of importance. Is #1, lack of standard assembly models, the biggest issue? Or is it #10, the lack of the killer app? Hard to tell. My guess is that there is no significance to the order, which is my only problem with the list.

To me, there is one enterprise mashup issue that rises to the top of the list, and it’s so obvious that sometimes I think it’s the elephant in the room that no one wants to talk about.

Security and control.

Sure, Dion talks about ‘security and identity’ but I’m talking about a more fundamental problem. Client-side mashups are the very definition of a CrossSite Scripting vulnerability: All data swims around in your browser and can be accessed by any JavaScript that get’s loaded there. That’s something that most enterprise Chief Security Officers and Chief Compliance Officers are not going to look too kindly on.

How can you get your mashup to be more precise about the data they access? How can you gain control over this?

Anant has been talking about this for a while in his Info 2.0 vision, even though it seems to go against the grain of Web 2.0.

Don’t get me wrong, I’m a huge fan of client-side mashups. It’s just that I think there’s some work that needs to be done up front before this architectural style can flourish within the enterprise. Server-side mashups have some of the same issues, but not to the same extent. I’ve written about the mashup stack before, which references some of Dion’s earlier posts. To me, the server-side mashup is where things are going to begin in the enterprise. There are lots of good reasons that IBM’s QEDwiki is a server-side mashup platform.

To me before you see mashups penetrate the enterprise they’re first going to have to build out data services. Once data services have been established most, if not all, of the security and control (as well as Dion’s other nine) issues can be addressed.

I don’t think I’m alone in this thinking either. That’s what Microsoft’s Project Astoria is setting out to achieve as well.

‘But wait’? You might say. ‘Aren’t data services part of all that enterprise SOA stuff that mashups were supposed to avoid’?

Yes, that would be true if your SOA was for Core integration. But if you’re talking about SOA at the Edge of your enterprise IT infrastructure based on REST and Dynamic languages, you could avoid all that complexity and overhead.

And if you used SnapLogic for your enterprise mashup data services, you’d have the security and control as well.

  • Hi, looks like we are building a community!!! Way to go Chris.