LongJump, PaaS in a Box – Brief Notes

Just as hosters (folks who run big data-centers connected to the internet and sell the use on those servers to folks running web sites, apps, and other internet connected apps) are pleasantly finding themselves crammed into the “cloud” category, many application platform vendors are finding themselves recast as “PaaS” providers.

LongJump is one of these outfits who’ve I now spoken with a couple times, including earlier this week with CEO Pankaj Malviya. Put in brutally simplistic terms, the provide a RAD stack of software that helps developers create web applications backed by databases. A hugh amount of business applications – and consumer – are really just that: a web interface on-top of searching and changing a database, so that’s no poor niche to be in.

From RAD to PaaS

Back in February, LongJump started providing their platform to ISVs packaged to be used as a private PaaS, where “private” means “run on your own,” just as “private cloud” does. That is, these ISVs would use the LongJump platform to develop and then sell SaaS applications. This week, their CEO Pankaj Malviya updated me on the progress of this offering. We walked through a nice demo, including new features like “workflows.” “Workflow” in this context usually means a process involving multiple people who have all go through a cycle along the lines of: the creation of some task at hand, assign someone to do something with the task, get someone else to “approve” that the task is done. Throw in a “customer,” and you’ve got “BPM” ;>

Since February 2009, they’ve had 5 ISVs sign up, each creating of delivering SaaSes with LongJump in very narrow industries like electronic equipment maintenance, HR, and drug trial management.

PaaS over the ALM

One of the more interesting statements from Pankaj was that development shops were finding the lack of traditional (to use my modifier) ALM in PaaS development annoying. Folks like Force.com – and the wider “cloud” world” – the conceit goes, don’t provide enough hooks to fit into the software development process that people are used to. The thinking is that there’s a cultural mis-mapping between how people want to develop software for the cloud and how the cloud wants (if only by omission of other options) people to develop software. Bringing up the specter of ALM-weakness is a good ploy and segmenter: if you know what ALM means, you probably like it, and if you don’t know what ALM means, you’re probably not worth selling to. It’s like command-line vs. “dashboards,” in that respect.