Image: ISVs have long used abstraction to isolate applications from technical implementation details. SaaS is based on services that can, and will, disappear just when you need them. Fault tolerance is no longer nice-to-have.

Whether using frameworks, cross-platform toolkits or even application generators, abstraction has worked well for the different combinations of OS, database, networking and user interfaces that confront on-premise developers.

As an SaaS ISV you only have one platform–what technology doubts could you possibly have to worry about?

For SaaS it’s services, all the way down…

SaaS applications are large portfolios of services that extend over the complete hardware and software stacks, including:

• Utility computing services for hardware, data storage and networking
• Common system features, such as billing, subscription management, analytics and service management
• Common application features, including charting, mapping, search and many others

Your customers do not count your technology as a benefit to them. They will not accept premium pricing. As a result, you will only ever have time and money to invest in building services that are core features for your vertical niche.

It makes financial sense to buy-in most of your services; keeping your running costs strictly under control. Your service portfolio can, and should, change in the future as you look for opportunities to swap to something cheaper.

As an SaaS ISV you now have total independence to choose the services you need for your application–where are the technical doubt and implementation differences you need to hide with abstraction?

My service was there a minute ago!

Technical doubt for on-premise products could usually by fully resolved at build-time. Once the customer had installed the product the IT setup changed slowly, if at all.

When a 3rd party supplier disappeared, or dropped support for their product, there was no short or medium term impact on any of the installed applications. These continued to run as before–often for many years. There was enough time to consider replacements (and you abstracted the interfaces anyway).

The services world of SaaS is different–the services you carefully selected can (and will) disappear at run-time! This could simply be from a temporary network outage. More seriously, a provider might close and stop offering their (probably in perpetual-beta) service with little or no warning.

Service outages can impact all of your SaaS customers–and quickly. The buffer that exists in the on-premise world between off-line development and build, and on-line deployment has disappeared.

If a service is unavailable you need to have a plan B in place. You cannot wait and develop a replacement solution in days, weeks or perhaps even months. Your customers have already noticed and they are waiting…

Without your having had any choice in the matter, SaaS throws you head first into the real-time world. You have to build a reliable SaaS application based on a large portfolio of (assumed to be) unreliable services. This is not easy.

Fault tolerance–here comes SaaS, ready or not

You SaaS application must degrade gracefully as services come and go. No matter what happens, you must always deliver the best possible customer experience. How it degrades depends on the missing service or services. An unavailable charting or mapping service clearly has a different impact than a missing database or networking service.

Your SaaS application must handle missing and unavailable services well, and tell your customers what is going on. It cannot just fail because a service is unavailable–even if it is something critical such as your login or security service.

All SaaS outages have an all-too real potential to blow up into a PR disaster. Bad press is not healthy for your reputation or keeping customer trust–both of which are essential for success in the SaaS market.

This time your main technical doubt is not the easy API differences between implementations–the main issue is the concern that any of your chosen services will actually be available from one transaction to the next.

Hiding behind abstraction will not work. You need a more flexible approach that handles unreliable services and guarantees an excellent user experience–no matter what service fails or disappears.

Coming up…

Are you forced to develop this supporting service infrastructure yourself, or are there standard solutions you can use? That is what I will look at in my next post on PaaS Talk: Might Amazon EC2 cloud platform squeeze the profits from SaaS apps?.

Image: Supporting multiple platforms has always been an issue for ISVs. At first sight SaaS washes this problem away once and for all. If only that were true.

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 30 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 PaaS Talk: Why hiding behind abstraction is not enough for SaaS applications.