While agile software development is centrally about the project management aspects of programming, and a flexible, unencumbering methodology to get to a better end product, few tools in the process actually have to do with the rapid creation and recreation of applications. Agile is an approach at the problem, but in the end, traditional compile, check-in, test, debug, re-check, test, provision, etc. of the application cycle are still very much part of the blocking and tackling developers need to do.

Enter PaaS.

First, I’ll admit right now, I’m not a developer. I’ve written some applications before in a variety of languages including assembly, C++, Pascal, Java, and BASIC, but coding was not my calling. However… as a business user, there is some real advantage to the PaaS model, especially as it crashes into a sustained, cooperative relationship with agile developers.

Specifically two major points of the Agile Manifesto (”Customer Collaboration” and “Responding to Change”) are inherently easier in a PaaS environment. PaaS provides a significant amount of customization and configuration at the non-coding level, which can deepen a user’s commitment to the application.

For example, I can “self-service” myself to design some very sophisticated automated actions or generate elaborate reports, normally reserved for a DBA and programmer. Such as with LongJump’s data policies or workflow or validations, many automated processing functions are laid out in an easy-to-convey way. I just have to have an understanding of how to dissect the data.

And when I reach my limit of expertise on the design platform or when the platform’s native functionality reaches a wall, I can turn to my buddy, Joe the Agile Software Developer, and say, “Can you write me a connector to our backend such-and-such?” or “Do you have time to write me a simple cleansing algorithm to hunt down bad email addresses?”

The parameters are fairly well defined. The constructs of the platform are very clear. Best of all, changes can happen in near real-time. If Joe writes a Java function for one of our objects, it can go live immediately without having to reinstall a thing. Checked in code is usable the moment it leaves Eclipse. While web developers might say “so what” to that, for enterprise developers, it can be something prized.

And if Joe’s code is close enough to what I need for another object, and I can read enough of it to know where my differences are, I can copy and paste the code for use in another object. It becomes one less thing Joe needs to do for me (freeing him to play WoW or whatever it is programmers do with free time — probably read about coding).

The end result are applications that not only work the way the end user needs them to (point number 2 of the manifesto), they are essentially alive – adapting whenever I have a new business need. And the realization of those changes are not measured in weeks or months or even days – more like minutes.

As a business user, because I’m tailoring the app to my own needs, there’s also a real stickiness to it and more satisfaction as we grow old together. As I mature, as our processes mature, the app matures with me. It’s mine.

And isn’t that the point of agile development?