David Berlind hosted a panel on enterprise mashups, with Michalene Todd of Serena, Nicole Carrier of IBM, Lauren Cooney of Microsoft (recently of IBM) and Charlotte Goldsbery of Denodo. I was supposed to moderate this panel, but when the vendors started treating it like a sponsored panel by switching out participants, and the conference organizers refused to kick in for any of my expenses (in an outrageously biased policy where they pay some speakers’ expenses but not others depending on who you complain to), I decided that it wasn’t worth the hassle and bowed out. David’s a great moderator and knows a lot about mashups, but ultimately, I think that he allowed this panel to be hijacked by the vendors, with the exception of Lauren, who speaks her own mind rather than the Microsoft party line. Serena totally screwed up on this one by bumping Kelly Shaw off the panel — a panel that’s described as being full of “girl uber-geeks” — and replacing her with a non-technical corporate marketing person who was out of her depth, and Denodo didn’t do much better by putting in a self-described salesperson.
There was an interesting discussion about how data is exposed to be consumed by mashups, e.g., ATOM/RSS, and the implications with respect to the security of the underlying data, the ability of mashup platforms to consume that data, and how to appropriately encapsulate data so that a non-technical person creating a mashup can’t do evil things to the underlying data source, like doing a search on a non-indexed field in a large database table. You need to consider the interfaces for accessing the data and services: SOAP, RESTful services, web services, etc.
Realistically, business users still can’t do mashups, in spite of what the vendors tell you: there’s just too much technical stuff that they need to know in order to do mashups still. Although it’s easy to drag and drop things within a graphical environment, that’s not the issue: it’s understanding the data sources and their interactions that’s critical. The real target for many of the mashup platforms, as I’ve stated many times before, is for the semi-technical types within business units who are now creating end-user computing applications using Excel, Access and other readily-available tools. I don’t think that’s anything to be ashamed of, and striving for the goal of allowing any business user to do mashups is unrealistic. I was at a client site recently, and of all the claims adjusters and their managers who I talked with there, I can’t imagine that a single one of them would be inclined to even try to create a mashup or — without intending any insult to them in any way — have the skills to do so. Likely the closest that business users will come to building mashups will be configuring their own personalized portal within an existing framework, similar to iGoogle; a proper mashup framework may also allow the portal widgets/gadgets to interact, such as using selections in one widget as a filter for another on the same page. A lot of the good business applications, the things that are now being handled by other MS-Office-based end-user applications, are spreadsheet-like in nature; data visualization is a critical part of mashups, but there’s rarely a Google map involved.
Another issue is whether mashups are ready for prime time: are they really intended to be deployed as production applications, or are they just an easy-to-use prototyping environment? What about underlying data sources that aren’t under your control (like Google Maps) in terms of SLAs and fault tolerance? Although internal systems can also have failures, at least you have some degree of control over your own IT resources in terms of high availability of applications and their data sources, and any critical external services that you use — whether in a mashup or any other type of application — has to come from a company with whom you can nail down a believable SLA.
Hi Sandy, too bad about this panel. Heard the same from others as well. Curious to hear more about the skill set required for Enterprise Mashups. Completely agree with your point about data visualization being critical as well as the issues surround security performance, etc..
Related to the mashup theme is the BI 2.0 theme, that also fundamentally relies on this kind of data access. I’m not a BI practitioner, but from what I know there are smart client tools (sometimes called data browsers) that consume data feeds like a mashup but also allow for complex manipulation, visualization, etc. Do you think BI analysts will fall short of the skills necessary to use the emerging 2.0 technique?
You obviously feel what you feel so I can’t argue with your feelings. But Ithink “hijack” is a bit strong. It makes it sound as if each of the panelist stood up and did a powerpoint on what they offer (which of course was hardly the case). If I or someone in the audience asks a question and someone on the panel chooses to answer it with a we do this or that, there’s a difference between being rude and interrupting that person and bringing the dialog back to the questions and issues that of import to the audience in the room. I believe a “replay” would show that I gave each of the panelists an opportunity to describe what their roles are at the beginning. but much beyond that… when I heard the marketingese start to roll-out, I politely interjected and brought it back to some issue that offered a takeaway for those in attendance. I heard the term platform get raised and, doesn’t servicized data insulate the underlying platform (thus stripping platform out of the conversation?). We cut that discussion of pretty quickly. In fact, I continually reminded the panelists publicly that we’re shooting for take-aways for those in the room.
As far as take-aways, you identified some important ones in your post, but there were others….for example before simply wrapping some data-source as an RSS feed or RESTful service, establishing policies around access control and considering where in the “mashup stack” such security policies can be implemented. We talked about how brittle mashups can be an how important it is for enterprises to take this into consideration as any mashups they are considering look to incorporate source of data and functionality that are outside their control.. particularly in the case of business process automation where that external service is in the critical path of the process.
Anyway, Sandy.. you obviously feel the way you do. So, I can’t tell you that you’re wrong to feel that way. All I can do is try to defend the panel as best I can. You were there. Half the room identified themselves as business people. Half the room identified themselves as IT and the range of expertise was nil to expert. In one hour, to cover the the information needs of such a diverse audience is pretty difficult given that entire multi-day events are dedicated to the matter.
David
There are 2 streams of discussion in Sandy’s post – one about the conduct of the panel and the other about Enterprise Mashups. My observations on both
On the panel itself, the composition was split in a way that we had representation of both ends of the technical/product manager and business user spectrum which makes it difficult to moderate it, but David Berlind did a good job under the circumstances. It was important to discuss both sides of the issue, and it might have been better to take up topics in succession from business value to technical implementation and be much more directed in who commented on what and in what order.
On the use and deployment of Mashups technology, I had the privelege of discussing the topic from 2 perspectives in the same week – Monday and Tuesday at the Gartner Application Development, Architecture, and Integration summit in Orlando with IT emphasis and then here in Enterprise 2.0 with a more business user emphasis.
I agree with Sandy’s principal conclusion that most mainstream business users don’t have the ability or inclination to “develop” mashup applications but would personalize them. Some would go beyond, but that would be a small percentage. Even Kelly Shaw who works for Serena made this point in her recent blog, and noted that this might not be Serena’s marketing stance.
The best way to think about Mashups might be in a tiered fashion with each tier having a value and users who enable the next tier. A simplified view of the tiers would be: Level 1- Enabling Mashup Data Services from a broad range of information sources. I use the word “data services” (a Denodo approach that serves both Business Mashups AND SOA Applications), while others like IBM use the idea of “Mashable Feeds” – its roughly the same idea. The ideas of security, data governance, SLAs are managed at this level which is firmly in the hands of IT. Level 2 – Creating Mashable Widgets – this goes beyond information/data to incorporate some basic functionality or logic similar to a mini-application. If composed of enterprise applicaitn functionality snippets, then this is still the domain of IT, but some simpler widgets from the Web may be constructed by the “uber-business user”.
Level 3 – Composition of Mashups – either from Data Services or Widgets. Basically this is mashups on top of mashups. Some call it composite applications. This is optional, but can be quite useful where no current application functionality exists. You’ll see why its optional in the next level
Level 4: UI. Creating a personal mashup page or portal page may be a way to demo Mashups, but in real business world, most users have their primary work interfaces and don’t want or need another one. Mashable Widgets or Mashup Data Services can be consumed or imbedded directly into application functionality or UI that business users are using TODAY — So think a widget or data services that is integrated within your CRM or claims adjudication application or the UPS-man’s handheld device. This is related to the argument about Level 3 being “optional” because existing applications or middleware (like BPM) might allow for creation of composite applications by leveraging mashable widgets and Mashup Data Services.
I believe in the power of “front-line” users adapting resources available to them to get most value from them – -but they have a job to do and it is not IT’s job. IT must ensure security, scalability etc and enable the front-liners.
Therefore if I were a business-minded CIO, I would think its more imperative to develop Mashup Data Services and Mashable Widgets with “good enough” (depending on purpose) security, reliability, service levels etc. FIRST and make them visible to business users and application developers to leverage within current applications and UI (hence the overlap with SOA initiatives), and have a limited number of advanced business users (business analysts even) experiment with mashup-building as a way to identify new use cases.
For full disclosure – I am VP of Marketing for Denodo and speak from the experience of nearly 100 enterprise customers doing some form of Mashup applications in NA and Europe.
Addendum: So what differentiates a Mashup Data Service from simply Data Integration and Mashable Widgets from SOA components? The differences today are along these lines, but eventually the two will merge:
– breadth of sources – internal and external, structured data from applicaitons/RDBMS/WebServices/XML, as well as web-extracted data (inherent but not explicit structure) and completely unstructed information (email, pdf, files)
– Architecture and interfaces – Greater Web-oriented architectures and interfaces like REST webservices, RSS/ATOM rather than “strongly-typed” interfaces
– Ease of Use in mind — masking of complexity using wizards, dropdowns etc.
– Acceptance of Variable Standards for Security, Reliability, SLAs to balance with “business value” — Not everything needs to be 4-9’s. But being able to manage and govern this differentiated standard is still very very important. More focus on agility, enabling business user value creation.