I'm having a strange chocolate and peanut-butter moment with two conversations springing from recent posts. The second, with Jonathan Sapir regarding the recent acquisition of PaaS firm coghead by SAP which is leaving former Coghead customers out in the cold, has lead me back to the first, with Mike Ogrinz regarding the advisability (or not) of equating new technologies with old, specifically vis a vis Excel spreadsheets and the modern enterprise mash-up.

I think the resulting "virtual conversation" (a sort of mashup of its own) is probably worth further exploration and deserves a broader audience so I'm turning it into a post of its own.

The question in the wake of the Coghead event was how much grief potential customers might be in for when their Platform as a Service provider took away their platform, leaving them with data which could be easily retrieved and applications which might not be (although, as Jonathan points out, this might not be quite so complicated as I initially imagined). Jonathan asserted, however, that by their very nature applications developed on such platforms would be small, reproducible elsewhere at modest expense, and ultimately worthwhile even if instantiated relatively briefly. His specific comment:

My thought on this is that if you are able to get x years life out of an application that cost very little to write (and otherwise might not have been written because the cost was prohibitive at the time), it still would have been worthwhile, even if you have to re-write it.

This flashed me back immediately to my previous conversation with Ogrinz over centralized control of enterprise mash-up tools, where I was arguing the other side of the issue. There, Ogrinz was asserting that control and reuse were the pre-eminent factors. His comments on the "bang-it-together" approach:

...I will say it's similar to the rise of "do-it-yourself" home centers. I am sure that a large number of the people I see in Home Depot go home and build complete garbage. But - it serves their needs. Maybe the bookcase looks horrible and will fall over when someone bumps into it - but it solves their immediate problem and they feel a sense of empowerment having built it themselves.

BUT - at some level a minimum level of quality that is assured by the "provider". The lumber isn't rotten, the screws don't bend, and the paint is lead-free. This is how I see enterprise IT's new role in the emerging mashup landscape - delivering the working parts that help mashups work. And the socializing the solutions users create.

These are not, of course, diametrically opposed views. They're not in precisely the same context, after all, and Ogrinz sees the value in the low-cost, do-it-yourself model. But it got me thinking about the classic problem we were discussing viewed in a more modern context: end-user application development using simplified tools outside the purview of the IT department.

Now, my entire point in critiquing Mike's original blog post was to avoid trapping oneself by evaluating modern technologies by comparison to the outcomes from using older, apparently similar technologies, so I want to be careful using the Excel comparison here. But it strikes me that it may be more apt in this context than where Mike originally applied it: both business logic and data are being stored outside the realm of the corporate IT department, and quite possibly without their knowledge. Both Mike and I recognize the danger of this scenario in the long term, having seen tremendous wastes of effort duplicating or reproducing logic or data which was originated through such mechanisms. Jonathan, on the other hand, doesn't see the downside in such a scenario; since the original effort must have been minimal, reproducing it should not be excessively costly.

I do not have an answer to who is right here, which is why I am making this post: your feedback and comments would be appreciated. I will say that I do still believe that centralized corporate control of data is important, and that IT involvement with development efforts, even casual ones, is desirable. I've too often seen the cheap, quick little application that someone produces to scratch an itch organically grow into something it was never originally intended to be, and result in horrific expenditures to fix or replace. At the same time, I also believe that pushing to tools down as close to the end-user as possible to allow them to scratch those itches, in ways which will not ultimately be harmful, is of vital importance to the future of IT. The question is, do easy-to-use PaaS providers like Coghead provide powerful tools as an important, cost-effective service without long-term consequences if they fail, or do they tend to lead to the dark side of data and logic silos which are expensive and time-consuming to climb out of again?

So; what's your verdict? Rapid web-based application development good? Or evil?