I asked on last week if rapid web-application development tools were good or evil and received a couple of interesting responses.

Ed Loessi, CEO of PaaS provider Faulkner Technologies, represents one commonly held view (at least, common outside IT departments):

A fundamental reality of business is that data evolves and grows more valuable over time and subjecting 'early' data/ideas to most IT processes stifles the innovation hence the reason most business people will do almost anything before they take a problem to their IT departments to ask for their help.

This is unfortunately all too accurate in many organizations, but it ignores both the perspective of the CIO and the long-term effects of such thinking, which is to effectively silo that valuable data and reduce its value to the organization. Innovation, after all, is worthless without an application to real business problems. Ed might discount the value of building a business case and projecting ROI, and certainly this is sometimes overblown, but we often forget that simply because a user has a good idea and access to some tools, it doesn't magically make what they are doing innovative. Business cases and ROI calculations came about in the first place because the preponderance of such efforts were exactly the opposite: duplicative and inefficient. If you learn nothing else as a CIO, it is to avoid building scenarios around the ideal rather than the average. Of course everyone using these tools imagines they are being innovative and it's in the vendors' interest to encourage that meme, but the CIO has to provide the reality check.

Ed also suggests that experts can be brought in when they are needed to corral these silos at little cost but it's been my experience that even terrific tools can be used so poorly as to make this a much more difficult endeavor than he implies. Many PaaS and SaaS tools have excellent collaborative interfaces to such information, but the fact remains that it is often duplicative of information already stored within the organization and that it may not have sufficient controls to keep it safe and secure. Again, this isn't of much concern to users, but I think it's something the CIO needs to address, even if it's inconvenient or unpopular. Mike Ogrinz nailed the impetus for this when he commented on the mashup/Excel question that it is "...somewhat naive in heavily regulated corporate environments. The end user who uses mashups incognito to circumvent terms-of-use agreements, subscriptions, or security policies is going to create huge liabilities for his or her organization."

In a "ripped from the headlines" example, the news that broke this weekend revealing that a file-sharing program installed on a defense contractor's PC accidentally released the blueprints from Marine One to Iran is a perfect example of one of the risks IT departments face in empowering users by allowing access to Web 2.0 technologies. Was the application innovative? We'll never know.

At any rate, it's clear at least that my initial concerns over the ease of reproducing these applications on other platforms was vastly overblown; subsequent events have once again demonstrated the resiliency of "aaS" solutions, as Coghead competitors have brought out one automated solution after another and customers have switched with truly minimal efforts (admirably detailed here by Phil Wainewright).

Jonathan Sapir pointed out that this approach of empowering users isn't anything particularly new, and that the reality is that users will always try to build their own tools, and IT's best response is to facilitate this effort while making it safe and effective. I agree wholeheartedly. In fact, I think it's more important to adopt that approach now than ever.

As I pointed out before, it's easy to see the cycles in IT; what is difficult is to judge their true similarities. I think that even though the approach of dealing out expertise and pushing tools down to users has been tried before, this time it is different. I think that some combination of the increasing technical sophistication of the average user and the dramatic simplification of extremely powerful toolsets makes it much more realistic for users to perform certain aspects of their own programming. I think that make's Jonathan's point more salient than it ever might have been in the past.

There is a lesson here for CIOs, which represents another cyclical sort of realization: don't let your users get ahead of you on the technology curve. There are good, time-tested reasons that they may not understand which may compel you to insist on particular solutions or restrictions on how they process data, but you have to avoid your IT department becoming a "culture of no" and driving users into the arms of Web 2.0 providers. It's clear that is absolutely the business model for many of these companies; they're not selling solutions to you, they are selling them to your users.

It's incumbent on IT to recognize this new state of affairs and to become the delivery mechanism for those tools. These are just tools; good or evil is how you use them. You have to be a trusted partner, or you are going to be pushing people into the arms of vendors who could care less about your internet security software and efficiency problems, and those tools will be used for evil, rather than the good they could provide both you and your end-users.