I'd like to start off by thanking the submitter for pinning the definition of RAD to a specific timeframe. If you check Wikipedia, you'll find RAD discussed in terms of methodology. Those of you who were developing in the early 90's will remember RAD as something completely different: namely, a revolution around tooling.
Starting with Visual Basic (fathered by User Interaction guru Alan Cooper), and later tools like PowerBuilder and Borland's Delphi, developers were able to create applications by dragging reusable components onto an "assembly canvas" and writing simple script code to connect them. This was revolutionary. You didn't write the code to create the user interface; you manipulated its components directly. After decades of talk about re-use, Visual Basic "VBX" widgets were one of the first truly widespread success stories.
At the same time these tools emerged, the notion of a client/server architecture gained traction. All of your presentation logic sat on the user's desktop, and the bulk of business processes and data resided in a central (usually SQL) database.
This was what RAD was in the 90's. The skill-level required for application development had suddenly been greatly reduced, while simultaneously architecture and infrastructure were greatly simplified. This allowed work to be easily broken down: one team doing the business analysis, another coding the user interface, and another designing the database and writing stored procedures. That division of labor necessitated that teams deliver assets quickly because of their interdependent schedules. But projects still mostly ran under a modified waterfall model.
What happened next is what brought us to SOA and, eventually, enterprise mashups. As the Web gained momentum, businesses shifted funding away from heavy desktop application development. Systems had to be more scalable and more available than client/server allowed. Teams had to operate on "Internet time." More flexible and capable languages like Java gained prominence and pushed the old tools into obsolescence. "Client/Server" became a dirty word while "multi-tiered" was all the buzz. Reusable UI widgets gave way to the notion of reusable services, which was supposed to yield a more powerful re-use mechanism.
But when we made this switch, we lost the "R" in RAD. Architectures became more complicated as the industry embraced products like J2EE servers and ESBs. Although IT departments created catalogs of scalable, reusable services, who were their customers? In feats of technical naval-gazing, it was often the same team or department who wrote them in the first place. Sure, there still was reuse—but often at a more compartmentalized level.
This is where enterprise mashups have their starring role. Mashups serve as a bridging technology between the "old RAD world" of the 90's and SOAs. Mashups are the ultimate re-use mechanism because the end products themselves can be recombined into still new mashups. The tooling around mashups will remind you of the productivity you enjoyed decades ago but with a new twist: UI advances (and gains in the general technical acumen of end users) mean that non-developers can create their own solutions in many cases. This fresh audience creates a brand new market for enterprise services. And they'll get the benefits of quick application assembly, but this time with a strong architecture behind the scenes to back it up.
RAD in the 90's consisted of IT going door-to-door to build solutions for the business. Later, with SOAs, IT built internal services and then assembled them to meet specific use cases. It's almost like we were carpenters and if someone wanted a bookcase we'd go into their house, ask what they wanted, and then build it for them. Today, we can be more like Home Depot. Enterprise services are the lumber, nails, paint while Mashup products are the tools that pull them together. We still have general contractors (our existing IT staff) but we also have plenty of do-it-yourself-ers in the form of non-technical business users. Self-serve IT seems poised for explosive growth.
This was first published in February 2010