Attending the Yahoo Pipes talk at ETech... very exciting with respect to Pages...
Just announced, Pipes will now support XML and JSON as feeds. Point, click, build a Pipe, and expose it as a DataSpace in Pages over RSS. I can't wait to get home and play!
The term Mashup, a term that already feels stale, is being attached to all sorts of things these days. Whether it is real estate information overlayed on a map, or mobile-phone-uploaded videos illuminating a traditional-media news story, they can be fun to use and they can actually make our lives easier. Which is great. So let's rush them to the enterprise, where everything seems so hard to accomplish. Let's free the knowledge workers from the manacles of legacy systems and torrents of email. Let's let people think and act instead of wasting time finding stuff.
Imagine, for example, that your own life could be easier. I, for example, have found myself in one or two bug triage meetings. It is a necessary part of creating software. And it is painful. When we're talking about a bug, we want to know which customers it affects, and so we pull up customer incident numbers. And then we look at another system to see who those customers are, how many incidents they have, etc. And then we look at another system to see how large the customer is, how far away they are from deployment, etc. (Oh wait: did I just admit that we don't fix every bug?) Why don't we just build an application to pull all of this together in the traditional way? Well, its hard, and I'm not going to skip watching all those great sitcoms to write it.
But maybe it would be easier to think of it as a mashup. Maybe if we started writing UI components that could be mashed-up we'd learn something about how to do this in the enterprise. And then I remember: we're launching a set of new products this year to help solve problems like this, and has some great products out already that can help, so maybe those could be of some use. More about that later.
First, let's think about how the mashup problem shifts when you move from the consumer world to the enterprise:
Security and Identity
Most of the internet is public, so you can mashup that public stuff pretty easily, since anyone is allowed to see anything. Take some public tax records and some public maps and you have a nice application. But all of the juicy (read: really useful) data in the enterprise is only available to a select group of people, which usually does not include you.
So you need a way to know who is who when they're using the mashups, and the mashup needs to forward that identity on to the widget-producers that serve up the bits that are being mashed up. In other words, identity matters and needs to be preserved throughout the data lifecycle and preserved in the mashup.
That sounds hard.
Enterprise-readiness of the bits
There are little web apps sitting everywhere in your company written by contractors and interns and internal developers or downloaded from the web. There's probably a good bit of Java and .NET, and I'll bet you a dollar that there is some PHP or Cold Fusion or Perl, and a bunch of other stuff lurking somewhere as well.
If you want to turn one of these applications into a widget-producer (I'll start calling these mashup-ready-widgets pagelets, which I'll define in a minute), what do you need to think about?
Pagelet: a snippet of UI, much like a portlet, that can live happily on any page in the world, look nice in that page, and interact with other pagelets on that page.
First of all, what if the pagelet producer goes down? I hope that doesn't wreck my mashup. Once I expose it to a mashup, how much traffic can it handle? Oh man, I don't have any way of tracking that. Maybe I should only expose it to a limited group of people using the mashup until I know it is stable. I got so excited about exposing my Ruby app to a larger audience I forget to get worried about exposing it with a broader audience in mind.
IT governance (Including regulations and all of that stuff)
That brings us to IT governance. Which is boring, so we'll keep it brief. IT will love mashups because they will reduce IT workload. IT will hate mashups because they are ungoverned. Aren't they? They don't have to be, provided the following is true:
Budgets
Last point, I promise.
No one makes tons of money on add dollars in the enterprise, so there are fewer gaggles of torn-jean, designer-hair developers hacking together the next coolest thing. The budgeting cycle is annual, everything costs a million dollars, takes a year to build, is soon irrelevant. How do we change that?
Well, we need an approach that IT trusts, so they will cede control, but the governance stuff should help with that. Then we need it to be cheap to develop, and easy to change. If things are easy to try, and people are given the right tools, and it will make their life better, they will try. Let's call this the Selfish Principle. If I have to convince IT to build my Bug Triage Mashup, I will fail. But if the person that benefits (me) can build it (or convince my office-mate to skip a night of WOW to build it), and it will make their meetings shorter in the long run, I might pull it off. We need to empower the Selfish Principle, and the rest will take care of itself. Budgets won't matter, since budgets don't govern the "million smalls" of the long tail. You can I can each do a little bit of work to make our own lives better, and everyone will benefit.
Okay, enough drivel. This is a place to learn about a new product to make mashups in the enterprise not only possible but useful. I think its going to be a lot of fun, so stay tuned...
