SaaS is a dream come true for ISV development managers; finally there is only one platform to worry about. The long years of cross-platform development are over.

The bad old days are over where every customer had a different combination of hardware and software. No more support calls asking you to confirm in writing that you support version x.y of product z.

In the new SaaS world there is only one platform–the one you choose to run your hosted application. Even better, you have total control of your platform. What’s more, not just making the first choice, but for all future upgrades and improvements as well. Luxury, pure luxury!

So what if you choose to develop your application in Erlang, Groovy or even Wasabi? This time your customers don’t care at all about your technology choice. This is new and cool…

So, having got all the good points out of the way, there is still an issue to resolve. What platform do you choose to build and deploy your new SaaS application? Unfortunately it is at this point that platform issues start to intrude on the SaaS clean sheet.

Platforms are not what they used to be

In the on-premise world your customers demanded your application fit seamlessly into their existing IT world. This was a benefit of your application and so rightly flowed into the ROI calculation when evaluating your product.

That all changes with SaaS. Everything to do with your technology platform is now solely part of your internal cost base. No matter how good your technology might be, it will never again be part of the ROI calculation. Platform independence and ease of integration have now disappeared from your benefits list.

Your customers do not care about your technology–it’s your problem now. All they care about is the delivery of the service they have subscribed to. The bits and bytes of how you build it do not interest them. That is one of the attractions of SaaS. This is new and radically changes the ISV business model.

It helps to know the (SaaS) rules

Customers evaluating SaaS applications look at the core features where they see a real value. The other (80%?) of your application is just supporting stuff. While they recognise it, it is not something that they will pay extra to have.

This focus on core features opens the door to new players entering your vertical niche. The barriers to entry drop dramatically if new entrants only have to offer the 10-20% of features customers place a high value on. They can ignore the rest and so be quicker to market.

As with so many other industries, SaaS is driving an unbundling of business application features. Customers will only subscribe to features where there is a clear value proposition. Cross-subsidizing technical frameworks and nice-to-have features will be much more difficult to justify and sell. This unbundling is new and means ISVs must be much more focused on the saleability of each individual feature.

It is the early 1980s again

While SaaS is new, selecting the right platform and tools to build your SaaS application raises issues that would be familiar to an ISV from 25 years ago.

Now, as then, it is a young market with new ideas, technologies, tools and providers. Who will survive? What technologies will become an industry standard? Nobody knows, and that makes planning difficult.

Your customers do not care about your technology. However, If you make the wrong SaaS technology or provider decision then the risk is much higher that someone will notice–and quickly. And once one user notices, it will not be long before everyone knows. This is new for ISVs where there has always been a disconnect between off-line development and the production applications running on-premise.

While SaaS makes it easier to start using your application, it also makes it easier to move somewhere else. It is therefore critical to get your technology decisions right–each and every time.

Investing in technology might not be a good idea

SaaS changes the rules on deciding how to invest in development. Your customers only care about the features that they can see and use. Anything that happens behind the scenes does not contribute to the value of your application as seen by your customers. This raises the question of how much you can and should invest in these hidden features.

For on-premise it made good sense to invest to build a flexible platform to support the customer-specific IT variants. That way of thinking is no longer correct and can lead to financial disaster in the new world of SaaS.

Over investing in technology layers and frameworks just serve to increase your base running costs. Your customers do not care. They will not reward your cool technology with premium prices. Pushing your cost base up you makes your life more difficult and squeezes your margins.

When planning your SaaS technology strategy you must focus your development investments on core application features. Resist all temptation to start building supporting “stuff”. This is new and marks a big change in how we need to think. This will take much getting used to by ISV development managers; even more so by ISV developers.

Will abstraction save the day again?

The ISV’s traditional solution to technology doubt is abstraction. Data abstraction layers handled the doubts about which database would win in the SQL wars. GUI abstraction layers came into play when ISVs first needed to support Windows, Mac, OS/2 and X-Windows.

Does it make sense to take the same approach again and create an abstraction layer between the SaaS application and the underlying platform?

The answer is–it depends! And that is what I will look at in the next post on paasTalk: Why hiding behind abstraction is not enough for SaaS applications.