“We can just hack that together” has been the rallying cry for mashups for a long time already, before the word “mashup” ever hit the scene, and Cameron Jones led us in the last breakout session of the conference to look at how mashups can be used for prototyping applications. He’s doing Ph.D. research on mashups, so was able to give a bit of a theoretical view on horizontal versus vertical prototyping; it’s really interesting to listen to someone who spends many hours each day thinking about this stuff, as opposed to most of us who only think about it occasionally (except here at Mashup Camp). He’s looked at mashups as a general design pattern, including non-web mashups, and we discussed how the current range of freely-available and open source APIs and platforms makes mashups incredibly attractive as a way to build stuff fast.
I’m particularly interested in mashups for prototyping in two enterprise contexts: end-user computing, and actual IT prototyping.
In the first intance, I’m seeing that mashups could become the next generation of end-user computing as long as mashup applications can be assembled with a minimum of programming by a fairly non-technical user within an enterprise. In many back-office departments that I work with, there are a couple of people who create local applications like complex reports in Crystal Reports, databases using Microsoft Access, and a host of other mini apps that aren’t sanctioned or supported by IT. Think of this in the context of the mashup mentality that Joe Ortega is trying to build inside eBay. When you think about it, aren’t DDE/OLE and macros/VBA just the precursors of mashup mentality, although for desktop rather than web applications? If you give the same type of tools to people in an organization, but now web-based, there could be some pretty powerful end-user computing applications created and — because they’re on the web — easily shared.
In the second instance, actual prototyping that will be turned into a “real” industrial-strength application later, mashups could be used to create rapid iterations of a prototype that allow for user evaluation and feedback. The prototypes might not be high fidelity, but a mashup could actually be a functional prototype rather than one of those non-functional mockups that are too often used by IT now to try to elicit user feedback. The danger, of course, is that since the mashup is functional and it’s ready now, the users may want to use it even if IT is planning a fully-architected, hardened version of the application to be rolled out several months hence, and the mashup could become a de facto standard that is difficult to replace later. Depending on your opinion about the current state of IT development, that could be a good or bad thing.
There’s a third use case for mashups as prototypes, and that is for external mashup developers to create new functionality on top of an existing web service or application that later causes the web service/API provider to roll that new functionality into their core product. I haven’t thought too much about that one, but consider that the mashup developers become both market research and unpaid prototype developers in exchange for their free use of the underlying APIs.