RAD tools for CEP: the good, the bad and ...

On my drive home from work one evening I was doing my usual auto-pilot routine, listening to the news on the radio when I heard an interesting technology-related story. It was a discussion on how technology jargon seems to slowly creep into our every day language. Most of the story slipped by me, but there was that one phrase that stuck with me. Just imagine 10 or 15 years ago if you said to someone "I Googled his Blog on my Blackberry", what sort of reaction would you get? A blank stare? Deer in the headlights? Made me chuckle to myself.

Over the past decade (or two) a plethora of new technology has become part of our every day lives. Over that same period, the software business has witnessed incredible innovations, the maturing of long-standing technologies and new spins on tried and true ideas.

Rapid Application Development or RAD as it's been known has been around for many years and applied to the application development process in all sorts of ways. These generally graphical tools have been layered over traditional development languages and platforms all with the lofty goal of shortening the application development cycle. RAD tools have been given a number of different names like Visual Programming, Application Designers, Scenario Modelers, etc. RAD tools for building commercial database applications have been around in various forms for over 20 years, and they seem to resurface each time a new technology for application development surfaces. CEP is no exception; most if not all CEP vendors have a RAD tool as part of their product offering. RAD tools offer big promises, but do they deliver?

RAD tools are not a panacea, nor are they simply demo building toys either. Keeping the right perspective is important to getting the most out of them. RAD tools come in all shapes and sizes. For CEP the visual programming paradigm seems to have hit home. Given a designer's canvas one can visually wire together abstract elements or components to form an application. These components called smartblocks or operators are dropped on to a canvas and allow the programmer to wire the outputs of one to the inputs of another. CEP applications typically start with connections to one or more raw streams of data. These raw stream operators are then wired to other operators to perform a number of tasks – such as a derived event stream with a set of temporally sensitive statistics. Some CEP RAD designers also allow the programmer to add rules and execute actions on these streams of data in a work-flow like manner, again in that visual programming style.

RAD tools are often on the front lines when vendors show their wares to prospects and in the hands of an expert they're a thing of beauty. Whipping up a prototype application is always a big win and generally provides proof points of the technology. By their very nature they promote a certain style of programming. Unfortunately that style while great for quickly churning out functioning applications is somewhat of an opposing force to good application design methodology. As I mentioned, the value (or point) of using RAD tooling is to shorten the development cycle. Customer's initial reactions to this are always positive. Software development as we all are painfully aware is a labor intensive task. Anything to shorten the time and therefore reduce costs is clearly perceived to be a bonus. But RAD tools do not always promote the best practices. Please don't read this the wrong way; I'm not saying RAD tools inherently create badly designed apps. It's more the mindset and environment in which they're used. I'm sure we've all been there; first we build a prototype of something. Next thing you know it's pre-production and then deployed live (ahhh!). If you're lucky all's well that ends well. But applications need constant care and feeding. Even if the application's platform provides many of the 'ilities (i.e. scalability, reliability, high-availability, etc.) apps still need a good dose of proper design to ensure they can stand the test of time (i.e. long-term maintenance).

RAD tool's visual programming metaphor typically bears little resemblance to traditional development languages and therefore the techniques to development and debug tend to be equally unconventional. Due to their ability to rapidly try out ideas, RAD promotes a trial and error style of code development (i.e. try something, if it doesn't work try something else and so on and so forth…). I like to think of this as stimulus-response or behavioral code development. The developer simply observes the behavior of the RAD-generated application based on how the various abstract components are assembled. If it does not behave as expected, it's generally quick and easy to make a change and try again. The very short path from coding to testing promotes this style of development.

There are a number of other aspects of RAD that present challenges to application development. The visual programming metaphor is more restrictive in its ability to fully express semantic logic. There are always portions of applications too complex to express in that visual metaphor. Being able to seamlessly integrate with or connect to components written in standard languages helps to avoid working against the RAD tool instead of leveraging its power.  RAD tools are often code generators, meaning the assemblage of abstract components are run through a parser that spits out source code in a traditional language or in the case of CEP, the vendor's EPL.  Debugging RAD-generated applications can therefore present a challenge.  It would be ideal to be able to debug from the same high-level operator view point used to create them, instead of trying to decipher machine-generated code.

If RAD was really a bad idea, I doubt it would have survived as a staple in software development for two decades. That short development cycle is a major benefit in fast moving business climates. Competitive pressures, especially in tight margin environments like Capital Markets have strained IT organizations to the limits. Tools to quickly push new and updated applications to the forefront can make a huge difference to the bottom line. But in the end, employing good design methodologies is a key part of the application development cycle. Rapid Application Development tools are just one means to breathe life into that design.

Comments

[Alyssa]

RAD BLOG!