As a developer you are the tailor, with access to configuration-ready suits and the ability to make edits to a suit as needed. You work with your customer, understand their needs, and guide them to the right configuration for their purpose. You help them try on the closest suit possible to what they need, and then you do your finishing work after you’ve met. When your customer comes back, together you try on the fitted suit and hopefully it is exactly what they need at that time. As that customer grows (or shrinks), you can help modify the suit so they get the most life out if it as possible.

What don’t you do? You don’t weave and dye your own fabric. You don’t re-invent cuts or create your own button holes. You don’t make your own buttons. In short, you don’t start from scratch. The result is that suits are made faster and relatively less expensively, and your customer gets what they want.

Agile Developing for the Enterprise Using PaaS

As more businesses and organizations begin to adopt agile methodologies to improve customer responsiveness and rapidly develop applications, it would seem that software tools have to be agile-ready. So far, most of the focus on those agile tools happens to be on the project management and delivery lifecycle phases, but what about the actual development of applications? Developers must examine how application creation tools can best support agile software development as a business strategy.

One example that comes to mind is the development of internal business applications. In the past, it was virtually impossible to build custom, enterprise-grade applications for every department. Now, because the current generation of users is so web savvy, having to deal with hard-coded legacy database applications and spreadsheets is not only ill-conceived and impossible to manage, it can ultimately lead to increases in operating costs and be rife with error.

The primary response from IT organizations has been to decouple the information from the application. Such is the nature of SOA/XML. That’s fine for the IT developer, but completely unusable from a departmental end-user standpoint – the people who have to use the data and face the information management challenges on a daily basis. They still have to rely on an in-house development resource or highly paid consultant to get to that data in a meaningful way that integrates with their work processes.

PaaS can be the ideal solution to solve that problem by making it extremely easy to design, develop, adapt and service web-based applications, while leveraging a comprehensive enterprise-class service environment. It is so easy to build apps that a significant amount of development and changes can be realized in a single meeting or overnight. This gives the user access to new functionality almost immediately. And very savvy users can even make the modifications themselves – simply by changing configuration options – offloading minor development tasks from the coders.

Our new whitepaper “PaaS and Agile Development: The Application Platform for Enterprise Transformation” covers everything a CIO, software product manager, scrum master, or architect needs to know about leveraging PaaS as part of an Agile strategy.

Technorati Tags: agile development, agile manifesto, agile processes, application development, cloud computing, extreme programming, PaaS, Platform-as-a-Service

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?

Technorati Tags: agile manifesto, agile software, application development, developers, programming