More SaaS ISVs to let enterprises have it their way on deployment models

I recently took an analyst briefing from Agile development and developer management vendor Rally Software, and while I'm very impressed with their new offerings and core value around bringing scale, feedback, and coordination to Agile development practices, I was really jazzed by the innovation they have brought to creating a hybrid, sort of sliding-scale approach with Rally Enterprise between on-premises software deployments and SaaS, or on-demand, delivery models.

Rally has done a super job at recognizing the value of an on-demand, SaaS model for developer activities coordination, especially with large development projects consisting of many elements, often done by various organizations and contractors at a variety of locations. Bringing the SaaS model to distributed Agile development is a no-brainer. SOA will be a huge opportunity.

However there comes with such an on-demand-only delivery move a need to evangelize on both the concept of SaaS, as well as the value of the developer productivity solution itself. There are those at enterprises -- a lot of them -- that will resist SaaS models, for any number of reasons. They should not, as a result of their predilection to on-premises control urges, be denied the fruits of innovative vendors like Rally, which for its own very good reasons favors a SaaS development and deployment strategy for its own software and solutions.

So Rally, which is managed by several former BEA Systems executives and recently landed a second round of financing, decided to take the SaaS discussion off of the table. They decided to let the buyers of their value have it their way -- on premises, behind the firewall, on your stuff -- or, off the wire from Rally's servers and hosting apparatus. Perhaps a little of both?

The really neat thing -- and which portends a likely expanding shift by pure SaaS vendors to hybrid models -- is that the have-it-your-way approach has proven quite a bit easier nowadays for SaaS vendors to implement, without wholesale re-engineering efforts. They can offer the on-premises value from their SaaS solution code origins by leveraging virtualization and behind-the-firewall appliances.

It turns out to be a lot easier to bring SaaS applications on-premises, than the reverse transition -- of transforming an on-premises shrink-wrapped product to a SaaS, hosted-solution offering. [Never mind that on-premises ISVs will likely see an abrupt, short-term drop in revenue by making a move from license to subscription pricing; another blog for another day.]

So how did Rally make their stuff available either as on-premises or SaaS? Did they re-architect the code, port it to the crap-shoot guess of the right platforms three years out, and then churn out a truck load of CDs? Nope. They toyed with the idea of creating an appliance that would drop in behind the customer's firewall, and offer sort of an internal tier to the otherwise SaaS application.

But then they got the virtualization bug, and saw the beauty of creating one image of the application that would run as a bubble on, for example, VMWare, within an enterprise's existing application infrastructure, whatever it might be.

Wow. So the enterprise buyer gets the application their way -- and no need to consider a platform/tools/object model/binaries set of issues for ISV. The ISV is free to also offer on-premises versions of their SaaS applications, all from the same R&D and development investments and code base.

What's more, the SaaS ISV gets to sell into the account on the terms the account wants, and then gets plenty of time to segue them over to the inevitable beauty of the on-demand model (at lower cost). It even gives the SaaS ISV a fatter margin on the on-premises sales. Or they get to innovate around a hybrid solution of on-premises and on-demand services (an extended enterprise SOA, perhaps?) -- but without the headaches of porting and deployment considerations.

The SaaS ISV can focus on a single, or nearly unified, code base and then deliver updates and new versions as needed, cost-efficiently to their virtualized applications, and their hosted services users, unbeknownst to all of the users. They can charge by seat, server, by subscription, or enterprise-wide -- whatever the customer wants (or market supports).

And so the question today is, why would any ISV interested in being in business for more than a few more years, develop to anything now but such a SaaS ISV-hybrid model? Virtualization is only going to be more common, and simpler, and less expensive. How much longer can the costly and inflexible lock between tool-application-platform continue?

It may make sense for large custom enterprise applications, but certainly not for competitive greenfield ISVs, Web 2.0 concerns, and the builders of service delivery platforms -- all of which are in a total cost of providership reduction race. If ISVs think that only walking with Microsoft into the future (as it increasingly puts up its own SaaS applications) is a good bet, consider that Microsoft recently bought an applications virtualization company, Softricity.

Will Microsoft use virtualization to make its own applications easier to use by it enterprise customers, or will they help their partner ISVs de-couple themselves from a pure .NET development and deployment scenario through virtualization? I have my hunches. It bears close watching how virtualization continues to upset the ISV-platform-framework allegiances apple cart.

Meanwhile, ISVs should hasten the move to SaaS and/or seek a SaaS ecology of development, such as Salesforce.com, and be based on a flexible virtualization play -- sooner rather than later. You're going to have to cut bait at some point, Mr. ISV, or you'll be living off of the dwindling support revenue from purely on-remises apps that will increasingly cost too much to build, deliver, update, and modernize. And your value-add of on-premises control will be but a chimera.