Salesforce dot what, now?

So, rapid application development.

In our space at least, it’s all about time to features. Not time to market, or return on investment, or any fuzzier metric, but simply; I need a feature, how long will it take? (And how much will it cost). Over here at Soliant we do business apps, meanings apps for businesses, workgroups, organizations, be they for-profit, non-profit, education, government, busy people who NEED IT RIGHT NOW. People who in fact NEEDED IT YESTERDAY but are being patient. Our challenge is always this: how can we deliver more features, better features, faster and cheaper?

The App Gap

For many years, in fact some generations now, the need for these workgroup apps, as we call them, has generally been met with on-premise client-server software stacks. OK, that’s a mouthful. It means that somewhere on a network I put up a server, generally providing database capabilities, and then I write a client app that knows how to talk to the server. And then I go around and put that client app on every single desktop that needs it. When the app needs revision, I may have to visit every desktop. In addition, client-server traffic is often fairly chatty. That’s the technical way of saying it takes a lot of network. But now we have massively distributed companies, virtual workers, telecommuters, road warriors, and you just can’t assume anymore that the people who need access to an app are necessarily going to be on a super-fast, high-bandwidth low-latency network when they need to access it.

Traditional client-server apps fare poorly under these requirements. Even with today’s higher Internet bandwidth, many of these apps expect low latency (roughly, how long does it take a single packet of data to make a round trip from client to server). If you’ve ever tried to explain to a harried sales manager why it’s taking him five minutes to enter each new contact into the corporate CRM system from his hotel room, you’ll know what this is about.

This of course is what led us to the world of web applications. No installation to speak of, and they run by sending lean, compressible data over the Internet. Lots to like. The only problem is, the Web is a truly terrible application platform. (Take this with a grain of salt: Soliant has built many very successful web applications over the years, apps that have delivered huge benefits that we’re quite proud of. I’m speaking in ideal terms here). The Web as such has little in the way of support for security, state management, identity management … the list goes on. And the request-response paradigm of HTTP in the past has led to apps that are notably less responsive-feeling than client-server apps built on platforms (such as FileMaker Pro) that offer highly responsive, highly interactive interfaces.

But now there’s AJAX! you say. Web apps that use AJAX for partial-page refreshes blah blah are making the Web (2.0? 2.3?) ever more responsive, more and more like a desktop app, but with massive deployment and scale.

Well this is all true, but there’s a problem with AJAX, and JSON and with all of the other alphabet soup of technologies we’ve used to try to lever these apps onto the Internet: PHP, JSP, ASP, Perl, Ruby, CSS, XML, HTML … I could go on and on. The probably with all of them is simply this:

They’re JUST TOO HARD.

It still just takes too long to build things for the web. You have to sort out servers, bring up databases, choose a platform, choose a toolset, choose frameworks … and then you have to code the thing. And you’re coding for a platform that never meant to BE an application platform in the first place, into which we’ve frantically been shoveling app-platform-like capabilities ever since.

I get that web app development time-to-features has steadily improved over the years. We’ve been along for the ride. I get that there are great frameworks that make it a lot easier than it was. I get that there are libraries that make AJAX manageable. I get that there’s Ruby on Rails.

But I don’t care. It’s STILL TOO HARD.

This, by the way, is why we love FileMaker Pro unapologetically. FileMaker’s time-to-features, if we could reduce that to some number would (I firmly believe) be the best on the planet. We use it for the vast bulk of our work.

But.

There is still that lurking deployment issue. People want their apps any time, any place. Sometimes installing a lot of software on the desktop just isn’t an option. Sometimes customers need to distribute an app to thousands of users across a wide geographic area. Sometimes they just want a web app. And so, we write web apps. Some darn good ones over the years, as I noted. But it’s nothing that, to date, you would have confused with ultra-rapid application development.

Now suppose, just suppose, there were a tool where I could build my data structure quickly, using point and click as I can in many client-server RAD tools. Where I could quickly prototype and polish a bunch of Web screens without crafting HTML. And where with a few clicks I could deploy my app straight to the internet, minus any fuss about servers, databases, software versions and so on.

Well, that would be the Holy Grail. Which is probably why so many are working on it. Many vendors of client-server RAD tools have added “web publishing” capabilities to their products, many of which do a passable or better job of turning a client-server desktop app into a workable web app. FileMaker Pro, again, is one such example. And there are services already in the marketplace, such as blist and DabbleDB, that approach the problem from a purely web-side perspective. With these tools, you build your app on the web, for the Web, end to end. Of these aspirants, one in particular stands out.

Like it’s 1997

The idea of apps that would exist solely on the Web (or “in the cloud” as it’s now cool to say) has been around almost as long as the Web itself. Back before 2000, we referred to this as the ASP (Application Service Provider) model. Vendors built web apps, then sold them as a service, on a subscription basis. There were many contenders in this arena, more and more as the tech boom swelled toward bursting. But it’s fair to say, in the aftermath, that no revolution occurred.

Why might that be? Well, these apps certainly solved the deployment problem. If you paid the fee and signed up, you could access your app from anywhere. But one problem these apps didn’t solve was the data silo problem. Each of these apps was its own silo, with its own means of storing data, its own standards and so forth. What if you wanted to get that data to your desktop? Massage it, analyze it, pass it around, maybe move it into other apps? Well, having your apps out in a web silo may not have made the matter significantly worse, but it certainly didn’t help the situation.

So then XML came along. And this was supposed to lead to a golden age of app-neutral data interchange, where all the world’s apps would send messages to one another and happily translate among a million flavors of XML.

And again that did happen, sort of. Except not quite, because this was also once again TOO HARD. App development technologies don’t truly begin to unlock human potential until they can be wielded, with reasonable effectiveness, by people who are not hard-core programmers. I love hard-core programmers. I love a good XSLT transform. I’ve written C, APL, Lisp, assembler, C++, Java. I’ve cared how wide my stack registers are. I’ve written double-buffered graphics routines. I’ve crashed machines with pointer errors. But … it’s not about me.

So I’m going to circle back to our topic now. Remember those ASP vendors? They didn’t quite transform the world, but some did survive, and even prosper.

Salesforce.com was one of those.

Isn’t that just a CRM app?

Salesforce was smart from the beginning. They recognized that mobile sales forces were among those who, in the mid to late 90s, suffered most acutely from the deployment gap. These folks were on the road all the time. Technology didn’t change that, but it did become ever more central to everything they did. So the sales force needed technology, needed APPS, more and more. But the tools for deploying those apps to them, and everyone else, lagged behind.

So Salesforce.com (SFDC from here on) entered the market with the admirably focused goal of solving the deployment problem for sales folks by building a web-based product tailored to their needs. And for many years they did just what product vendors do — added features, improved the ones they had, and worked on their underpinnings.

Of course, this was all a big web app. And so, in the course of expanding their product and their business, they did what they couldn’t help but do. They built server farms. They installed databases. They built data centers. They created programming frameworks and database abstraction layers. They created tools and technologies to whack together an acceptable presentation layer (i.e. web pages) quickly.

In short, they solved, for themselves, all the problems that make delivering apps to the web such a slog. They moved beyond building a product, to building a PLATFORM. And eventually, it became impossible not to notice this. the question began to be asked, perhaps by SFDC customers still struggling with the same deployment gap that had rubbed them raw for years, whether perhaps it might be possible to build OTHER APPS on this platform.

So somewhere, a light went on. Web-based products like SFDC had shed their pre-crash ASP label and been reborn as SaaS (software as a service). The opportunity for a new acronym was doubtless the icing on the cake. From Salesforce.com the web app was born plain old Force.com (or FDC), the web PLATFORM. Which we app developers can use to develop and deploy our apps, leading to a new acronym: Paas, or Platform as a Service.

So what?

The tech world is very hype-driven. I believe strongly that all new technologies need to pass the So What test. Is this thing that SFDC has done really significant? Isn’t it just a new permutation of the old ASP model, a model that had some successes but no revolution?

Well no, not exactly. The distinction between an app and a platform is critical. If I buy, or license or lease or subscribe to an app, I get the features the app creator has decided to put into it. My vendor may have a very open attitude toward feature requests. I may get to submit feature requests and lobby strongly for them. But in the end, the vendor decides what to build.

Not so with a platform. With a platform, I decide what to build. Of course, I still have to live within the native capabilities of the platform. If I need charting, and my chosen platform has little to no charting support, I have a dilemma. I can either work around it, probably shortchanging a business requirement, or I can roll my own, likely leading to a significant bump in development time and costs.

So yes, platforms do have their limitations as well. But with any reasonably decent platform, I can build things that are highly customized by comparison to packaged apps, while at the same time getting significant productivity boosts from the capabilities that are native to the platform.

So if I’m an app developer obsessed with time-to-features, platforms are good. And the arrival of a new platform that claims to boost the development of high-scalabilty, high-availability apps (which today means delivery via the Web) is … worth looking into.

When I next blog about the FDC platform, I’ll get specific about its ups and downs (it has a few of each). Don’t sell your old tools yet, but there are some intriguing things going on over there.