Image: The CloudStatus service reports Amazon EC2 health based on EC2′s network availability and compute availability.

It is important to know how reliable your cloud provider is. The SaaS community heavily criticised Amazon when they had outages in their S3 storage cloud. As a direct result Amazon rolled out a comprehensive Service Health Dashboard. This gives a good insight into what is going on with the Amazon cloud services.

Any dashboard provided by a cloud provider opens the door to tainting the truth on performance and availably. It could therefore be useful to have an independent source of metrics to refer to.

Image: CloudStatus reports Amazon S3 health by analysing PUT and GET operations from inside and outside the cloud.

Rather than spending time and resources on building such a monitoring system yourself, Hyperic has launched CloudStatus. This is a new cloud service monitoring and logging service. It gives another view into what is going on inside the Amazon cloud.

I think this is an interesting development and I congratulate Hyperic for making this service available. The more insight we have on cloud performance the better. Independent metrics help reassure SaaS customers that clouds are at least as reliable as in-house systems.

Image: Ise Grand Shrine is a Shinto shrine located in the city of Ise in Mie prefecture, Japan and is one of Shinto’s holiest and most important sites.

Akafuku was founded in 1707 and is Japan’s most famous sweet company. Their sweets are the traditional gift for visitors to the Ise Shrine, Japan’s holiest religious site. In autumn 2007 a story broke that shook Japan. Trust in the Akafuku brand built up over 300 years was not enough to protect them.

Akafuku makes bean-jam sweets (rice cakes wrapped in red-bean jam), claimed to be freshly made every day with any sweets not sold that day thrown out. This was not true. Akafuku had been lying for more than 30 years.

It was revealed that sweets not sold that day were not thrown out. They were frozen to be thawed and resold later. The labels of the frozen sweets were forged with future expiry dates. Japan was appalled and the impact was immense. It was if Starbucks was exposed for selling instant coffee!

Akafuku’s massive mistake

While there was no risk to health in what Akafuku was doing, it totally destroyed trust. When bringing sweets back home or to the office as gifts, the expectation was that they were fresh. Frozen sweets did not match the story Akafuku was telling.

Even with a 300 year track record, the Japanese were not prepared to forgive what Akafuku had done. The local government stepped in and Akafuku was forced to suspend production indefinitely. The flagship store at the Ise Shrine was closed and products removed from shelves all over Japan.

The lesson for SaaS

As a B2B ISV selling via SaaS must meet user expectations each and every day. In the sales process trust, and your service level agreement, were big issues. Now there is a risk standards will slip. What would never have been allowed at the start of the user relationship somehow becomes acceptable.

You must ensure what you say is what you do — each and every day. If you say one thing but do another, your subscribers will not forgive you when they find out. And find out they will.

Akafuku built trust with Japan over 300 years. Even so, when the truth came out it did not protect them. They were not doing what they said. Expectations were not being met and the Japan was appalled and stopped buying.

Subscribers have more choice

A key difference between SaaS and licensing on-premise software is ability to swap. SaaS subscribers feel it is easier to change when things go wrong. If you do not live up to their expectations then they will leave. And they will tell others as well.

I do not know if the system at Akafuku was approved from the top. It was likely a local decision. An employee had a lot of sweets left over one day and did not want to waste them. A one-off decision slowly becomes accepted practice. When the truth was revealed it cost Akafuku 300 years of trust.

Building trust is hard, losing trust is easy

You face the same risk. Any of your people could make a choice that costs you user trust. And what is worse, you can never keep any problems secret. On-premise software customers were isolated. SaaS subscribers talk to each other. A small problem can become a wildfire of upset customers.

Building and maintaining user trust is the most critical part of SaaS. It takes a lot of time and money to grow trust. It can take one comment on the phone, or a hasty email, to destroy it.

You must make visible to all of your people how critical trust is. It does not matter if they are user facing or not. All staff must be aware of trust.

Appoint a Chief Trust Officer

Consider appointing a “Chief Trust Officer” to show how critical trust is for you!

Winning at SaaS needs more than having the right technology and the right marketing. If you lose the trust of your subscribers they will head for the door. A story reaching back 300 years did not help Akafuku when they lost trust. The length of the relationship with your SaaS subscribers will not help you either. Lose their trust and they are gone.

Do you have a “Chief Trust Officer”? Do you make your people aware of the trust impact of their day to day actions? How do you monitor trust levels?

PS: The local government lifted its ban on Akafuku at the end of January 2008. Regaining 300 years of lost trust will take a little longer.

Image: 100% server uptime doesn’t matter to your customers if they can’t login because a digger has torn up the local DSL cable. End-to-end uptime is the only thing that really counts for SaaS SLAs.

Amazon S3 was down last week. A lot of blogs covered this, discussing the need for 99.999% uptime. A lot of people invest their time improving hosting uptime. Even so, 5 minutes and 35 seconds downtime per year is very difficult to achieve.

The thing is, 99.999% hosting uptime does not matter at all to your SaaS subscribers. What matters is that they can login. If they cannot, then no matter what the reason, your SaaS system is down.

We must stop focusing on hosting uptime. Instead we need to start thinking about the total user experience. End to end uptime is the only thing that matters to SaaS subscribers.

Only end-to-end uptime counts

In a previous life I worked with IBM mainframes. What counted was response time to the user’s terminal. A similar issue applies to SaaS.

Your subscribers do not care about hosting uptime. If they cannot login then your system is down. Oh, and it is your fault! It could be a network issue. It could be a DNS issue. It does not matter. Whether or not your hosting is up, if your subscribers cannot login then it might as well be down.

It is easy to focus on hosting uptime. This is the wrong thing to do. Instead, try to see things as your subscribers do. This will make your life more complex, but it is a major benefit to your subscribers.

Out of (your) control

There are many moving parts between your SaaS host and your user’s desktop. A lot of things can (and will) go wrong. Your customers have an internal network. If their switch is down they are cut off from the Internet and cannot login to your SaaS application. For them, your system is down.

You have no control of most of these moving parts. They must all work for your subscribers to login. Do not try to control things you cannot. Instead, focus on giving your subscribers the best possible experience. Especially when something fails…

When anything, anywhere, fails you need to know about it right away. How will you know? Your subscribers need to know. How will you tell them?

Communicating In times of trouble

You have a real-time service dashboard to show the live status of your SaaS application. This is good, but it does not help your subscribers if they have a network problem and cannot reach your dashboard. If your subscribers cannot login, and they cannot reach your dashboard, then to them you have suffered a massive failure. Even though in reality their switch failed, your system is up and all your other subscribers are working OK.

Some might argue this is not your problem; they cannot be expected to handle everything that goes wrong. This might be true from a legal view of your SLA. What matters more, though, is how your subscribers view such faults.

If they cannot login then their trust in you and your system will drop. No matter what the real cause of the problem might be, you will pay for all problems with your trust.

Trust makes it your problem

Getting and keeping the trust of your customers is the most critical part of SaaS. This is why you need to think about all the things that could go wrong. Think about these things now, before they happen, and put a solution into place. The investment will more than pay for itself when faults occur and your subscribers know right away what has gone wrong.

You must ensure your subscribers always know the status of your systems. To do this you will need to provide status details using an independent “control path”. When the network fails you still need to keep your subscribers informed. This was the mistake that Amazon made with their S3 failure. They did not communicate with their subscribers.

There are a number of ways this can be done, and I will be looking at these in future articles here on ISV Survival. In the meantime, how do you manage all the moving parts between your subscribers and your SaaS system? Does your SLA take such problems into account?

Image: Service level agreements will increasingly become a competitive differentiator in the SaaS market. How will your weasel worded SLA stand up when competitors offer real (and significant) cash for downtime?

Web news is talking about the 2 3 4 5 fibre optic cable breaks in the Middle East. While the net was designed to be up all the time, there will always be faults.

How do you react when a fault impacts your subscribers? Do you tell them it is not your fault? Do you tell them they must just put up with it? Today many ISVs are doing just that.

With no or very weak SaaS SLAs, at best customers might get a refund for that month’s service fee. Because no real cash is at stake many ISVs have not invested.

What, though, if SaaS ISVs had to pay a real (and fair) amount of cash to customers for downtime? We expect planes and trains to pay if they mess up our plans. Why should SaaS be a special case?

We can see how some ISVs value SLAs by looking at what they do and say when a fault occurs. Two recent examples:

1 Million 37signals users and still no SLA

37signals is well-known in the SaaS and Web 2.0 world. Often quoted as a good example of SaaS, all their products were down (again) for a few hours recently. This post was made on their product blog once the fault had been fixed:

… While we don’t have a formal service-level agreement (SLA), we still want to compensate anyone who felt they were negatively affected in their work because of this outage. Please write support@37signals.com (and include your application URL) and we’ll get that taken care of. …

With more than 1 million users, an SLA is the least users can and should expect. A lot of the user’s comments about this downtime were from consultants. They were relying on 37signals’ products being up and running. When they are down they could not work. I don’t know how much 37signals refunded users in this case, but I doubt it made up for the lost access to many users.

It is easy to say you are sorry for downtime. It is much better to show (with cash) how sure you are this is not going to happen again. Users that are paying for services can, and should, expect a real, tough and fair SLA from 37signals. As long as they can get away without having one it makes it a little more tempting to think that you do not really need one either.

SLA not necessary for on-demand FogBugz?

FogBugz is a bug tracking and project management system from Fog Creek Software. In the last 6 months or so they started an on demand version, which was down recently. Here are some quotes from their blog post on what happened.

The first quote is from their system admin:

… I know that we don’t officially have an SLA for On Demand, but I would like us to define one for internal purposes (at least). …

CEO Joel Spolsky then responded:

… But there are some problems with SLAs. The biggest one is the lack of statistical meaningfulness when outages are so rare. We’ve had, if I remember correctly, two unplanned outages, including this one, since going live with FogBugz on Demand six months ago. Only one was our fault. …

Downtime is always your fault. Your customers pay you money for the service. If you do not provide it, then it is your fault. The buck always stops with you. In this case they went on to make an offer to pay for the downtime:

… In the meantime, our customer service folks have the authority to credit customers’ accounts if they feel like they were affected by an outage. We let the customer decide how much they want to be credited, up to a whole month, because not every customer is even going to notice the outage, let alone suffer from it. …

The tone of this whole post is that an SLA does not mean anything. They claim it is not always their fault. In any case, many subscribers did not even notice. You might not see it this way if your team cannot work. Fog Creek should do better on reacting to faults. A real, tough and fair SLA would be a good place to start.

Planes, trains and SaaS SLAs

In the old days plane and train firms were not liable for delays. At best you might get a refund for your ticket. Tough luck if you had any other losses. This has now changed due to user pressure.

In the software world we have built a story that software is special. We say that it is complex so usual rules cannot apply. We see this story in the success of very limited liability for software errors.

Planes and trains also tried to avoid paying. They said delays were caused by acts of nature beyond their control. This worked for a while, but no longer. Why should software be special? Why should ISVs be able to get away with excluding risks that other industries can only dream about?

Cracks in the walls of (no) software liability

We all spend time and money working around security holes in our software. Why have these holes not been fixed? As the respected security expert Bruce Schneier explained back in 2004, ISVs have no financial reason to do so. The user pays the cost of the holes, not them!

Like planes and trains and their acts of nature, ISVs have been good at avoiding liability. This will not be so for ever. Many people no longer see software as special. For them it has always existing, like electricity. ISVs will have more trouble getting these people to sign old contract terms. They rightly demand the same rights for software as for a fridge or a TV.

If classic ISVs must pay real cash to fix things when they go wrong, it will be hard for SaaS ISVs to avoid the same rules. It should not change user’s rights if software is on-premise or SaaS.

Is SaaS more complex than an airline?

Like in bad old days or planes and trains, in these early SaaS days 37signals, Fog Creek and others can get away with no or weak SLAs. This will not last. As customers switch to SaaS they will expect to get the service they are paying for. If the service is not provided then their costs must be paid–in full.

The user’s goal with the SLA is not to make money from downtime. The goal of a real, tough and fair SLA is to make sure that you invest: You must invest time, money and effort to ensure that the risk and impact of downtime is very low. The cost of the SLA is the stick to beat you with.

An airline cannot control the weather. You cannot control whether a fibre optic cable in the Middle East breaks. Both can assume, though, this might happen. You can plan for this and include it in your SLA cost plans.

Having to pay real cash focuses attention

Your B2B SaaS customers that pay you real money will expect a real, tough and fair SLA. This is not to say all subscribers expect or need 24×7 access. For each user downtime in certain hours, days or months are a higher risk than others. Your SLA will need to take this into account.

If you have to pay real cash for downtime then you will do what it takes to avoid downtime. Problems will always occur and you must handle them in the right way. You can limit the risk of a large cash payout with insurance.

The first thing SaaS prospects will look at is your SLA. This must be very open and clear on your website for all to see. The terms must be clear and say what cash payments are made for downtime.

Comparing your SLA with those of other SaaS ISVs will become a key part of the SaaS purchase choice. You will not get away with hiding your SLA. You need to shout about how good your SLA is, not hide it! It cannot be a secret.

You need a real, tough and fair SLA for SaaS

You cannot plan for “Black Swan” events such as 3 meteorites hitting your 3 data centres at the same time. You can plan for fibre optic cable breaks. Assume you must pay real cash for downtime and your SaaS business model will be more solid.

Make your real, tough and fair SLA the core of your SaaS business model. Plan that downtime will cost you a lot of real cash. Do this and you will be a big step ahead of your competitors.

37Signals and others can win at the moment with no SLA. This will not last for ever. Don’t build your SaaS business model on the false hope you can get away with it as well.

It did not work for planes and trains, and it will not work for you either.

Image: A disk failure at an on-premise customer is their problem. If your SaaS solution is offline because of problems at your storage service provider then it’s now your problem. And that’s a new world of hurt you’re facing.

Data storage is very reliable, but still has unexpected and catastrophic failures. That’s why you backup your data. You must plan for when things go wrong. It’ll almost certainly not go wrong in the way you expected, but it will go wrong — sooner or later.

I’ve seen my fair share of data disasters over the years so I use a variety of media and archive cycles for local backups. For offsite backups I use Jungle Disk. Jungle Disk is a remote storage solution built on the Amazon Simple Storage Service (S3) for data storage and the Amazon Elastic Compute Cloud (EC2) for block-level file updates and other services.

As a Amazon Web Services user, I follow with interest the increasing acceptance in using Amazon’s S3/EC2 as a SaaS platform. It now seems to be the default assumption that Web 2.0 startups will use Amazon’s platform from day 1 to save a lot of money. Of course, they are also happy to leverage Amazon’s reputation: “If it’s good enough for amazon.com then it is good enough for our users…”

This is all well and good — until the SaaS platform fails — and it will — and then it’s your fault!

If you cannot provide your application services to your customers then it is always your fault! It will not matter what unusual and totally unexpected event has struck your SaaS platform provider.

If your customers cannot get at their data then it is your fault. The trust relationship you have invested a lot to build with your customer will be damaged. It is you that is going to suffer the consequences, not your SaaS platform provider.

Choosing the right SaaS platform

It goes without saying that it makes absolutely no sense for you to try to build and run your own SaaS-capable data centre. You must depend on one or more external suppliers for your SaaS platform.

To gain the trust of your customers, the level of service you commit to your customers will be higher than that offered to you by your SaaS platform provider.

This “SaaS Trust Gap” between what you must offer your customers — and what your SaaS platform provider offers you — is one of the major risks you must manage to survive and profit from the shift to SaaS.

The right choice of SaaS platform provider is therefore critical to your success.

SaaS platforms will always be unreliable

As the market for SaaS platforms develops they will become increasingly reliable. However, they can never be 100% reliable. For the short term probably. In the medium term probably. But in the long term, no. There are just too many things that can (and will) go wrong.

Assume for the moment that your SaaS platform is unreliable. How can you still provide a higher level of service to your customers than that provided to you by your SaaS platform provider?

The basic concept is the same as you are using today with storage arrays. Simply assume your SaaS platform is unreliable and architect your SaaS infrastructure around this fact of life.

My provider guarantees 100% uptime…

At this point you might object that your provider commits to 100% uptime. They have redundant power supplies, redundant Internet connections, fail over this and that.

While 100% uptime might be their stated goal, even the leading tier 1 data centres have major outages. Even Amazon’s widely-used S3 has not been immune to occasional downtime and claims of lost data.

Even if your deployment platform provider really was 100% available, that does not always help your customers. There are a lot of “moving parts” between your SaaS platform and your customers desktops. You will never be able to guarantee100% end-to-end uptime.

So, what do you do?

Standardised SaaS platforms?

In the ideal word there would be a standard for SaaS platforms and a range of suppliers competing on price and availability. You could then develop and manage your applications independent of the underlying deployment platform provider.

This ideal world would make it easier to move from one SaaS platform provider to another in order to improve service to your customers, and to reduce your risks as SaaS platform providers gradually catch up with the commitments you are already making to your customers.

The current market for SaaS platforms is too immature, however, for such a standard to have emerged. And, based on past experience, it is pretty unlikely that anything will happen anytime soon.

We are still at the stage of proprietary platforms, each with their own proprietary interfaces and architectures. We have the well-known players such as Amazon, IBM, Microsoft, Oracle, Salesforce.com etc, plus OpSource, SaaSGrid, FlexiScale and a range of smaller players.

I think the solution to this problem of depending on proprietary SaaS platforms is essentially the same one you have successfully applied to a whole range of technical problems in the past: abstraction.

Abstracting the SaaS platform

In the same way that you developed a “database abstraction layer” or a “platform abstraction layer”, you should consider adding a “SaaS deployment platform abstraction layer” to your application architecture.

There are already some SaaS platform technologies coming to market which are clearly moving in this direction.

Take the Amazon EC2 platform as an example. The Amazon EC2 architecture makes it possible to manage and run instances in a flexible, reliable and cost effective manner. However, the way in which you need to interact with the Amazon EC2 “management system” is fairly complex and proprietary.

To address this problem SaaS platform vendors such as RightScale and CloudScale are developing technology that abstracts away the details of the Amazon EC2 platform.

While the current focus is on making it easier to use EC2, the same approach can be extended to make your SaaS applications independent of the underlying SaaS deployment platform.

Leveraging the future

The market is driving towards “Cloud Computing” and “Utility Computing”, but those clouds and utilities will never be 100% reliable. An often-used analogy compares cloud computing to the electrical grid. We need to bear in mind, however, that more than 100 years later we still have blackouts from time to time!

A competitive market for SaaS platforms will emerge, but to benefit you will need to:

• Treat your SaaS platform as just another piece of technology to be abstracted away.
• Always bear in mind that your current SaaS platform will almost certainly not be your future platform.
• Protect yourself against being locked in to your current SaaS platform provider.

Image: Customer’s expectations of business applications are often driven by their experience of consumer applications such as Gmail and Flickr. If you’re only shipping on-premise products on CD then things are going to end badly.

in 2008 your customers will more and more expect you to offer your business applications via SaaS — whether you are ready to or not.

A long time ago (or so it seems) a similar tale unfolded as customers forced ISVs to shift applications from character mode to GUIs. The pressure for change did not come from the ISVs. I am sure you also had managers who thought GUIs were a backward step in productivity for business applications. Product managers often claimed “our users do not want a mouse.”

As customers became used to GUIs on their home PCs, they expected the business software they used in the office must also have a GUI — whether it really needs it or not. The exact same process is being repeated today with the shift from installed software to SaaS.

The pressure mounts on the vertical business applications supplied by ISVs as customers become more used to web-based applications. This pressure will only increase as web-based applications are getting better every day.

2 Web-based applications to sample

Why not invest a few minutes to see for yourself how good some of today’s web-applications really are?

Here are 2 web-based applications I have used that I think are good examples of the state of the art:

• The Picnik online photo editor is a leader in the ever-increasing range of web-based photo-editing tools. Graphic tools such as Adobe’s Photoshop are the classic examples of installed applications. Picnik shows that graphic applications not longer need to be installable software.
• The Squarespace web publishing system is a web-based application for creating and publishing blogs and websites. The layout and customizing options in Squarespace will give you a good idea of the rich user experience that your customers will be expecting from you from mostly text-based applications.

I think you will agree that these web-based applications are very nice and really rather impressive.

Are you keeping up with your customers?

Your customers are already using web-based applications such as Picnik and Squarespace in their “other life” outside of the office.

These are consumer applications so they are called Web 2.0 rather than SaaS. Even so, your customers are gaining a lot of experience with such web-based applications and this continually raises the bar on what is expected of you from your vertical business applications:

• Will your SaaS business application be as easy to use as Picnik or Squarespace?
• Will it be as much fun?
• If not, why not?

Make the most of the new web-based applications and get to know what is already possible. Do not lag behind your customers on what is possible with today’s web-based applications. Your customers will be expecting at least the same from your SaaS business applications.

Let your competitors repeat their GUI mistake

Many of your competitors are repeating the mistake they made resisting the shift from character mode to GUIs. They are holding meetings right now at which they are trying to convince themselves “our customers do not need SaaS”, or “our customers want to have installable software.”

Leave them to make their mistake — while you double your efforts in 2008 to rebuild your ISV to survive and profit from the shift from installed software to SaaS.

Thank you for reading ISV Survival in 2007. I hope that you are having a good break over Christmas and the New Year. See you in 2008…

Image: Nozbe offers a SaaS GTD solution, but read the TOS and you’ll think twice before “dumping your brain” there. Not to pick on Nozbe, but SaaS SLAs have a long way to go before users will entrust them their most critical stuff.

For day-to-day task planning and management I use a light version of David Allen’s Getting Things Done (GTD) method.

Earlier this year I saw a reference on the ZDNet Office Evolution blog to a new SaaS GTD tool called Nozbe from apivision.com. I was reminded of it when lifehack.org included Nozbe in their 11 Top New Web Apps of 2007.

Over the holidays I thought I would give Nozbe a try and see if it could replace my current Microsoft Outlook solution. My initial impression of the site was positive, until I clicked on the Terms of Service link at the bottom of the Nozbe home page.

When I evaluate a new SaaS service on of the first things I do is have a look at the terms of service to see if there are any traces of a SaaS Trust Architecture. What I saw at Nozbe showed little or no thought had been given to convincing qualified prospects (in this case me) to trust their company enough to consider taking the next step and trying their service.

Extract from Nozbe’s terms of service

Here is an extract from the “Service” section of Nozbe’s Terms of Service. I had added highlighting for the text which I immediately noticed:

“Apivision.com may suspend the Service for any reason whatsoever, including but not limited to, repairs, planned maintenance or upgrades, and will not be liable to you for any such suspension.”

“Apivision.com reserves the right to refuse service to anyone for any reason at any time.”

“Apivision.com may suspend the Service for any reason whatsoever, including but not limited to, repairs, planned maintenance or upgrades, and will not be liable to you for any such suspension.”

“Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account.”

“Apivision.com reserves the right to make any changes to the Service or to discontinue any aspect or feature of the Service without notice, and will not be liable to you for any such change.”

“Apivision.com, in its sole discretion, has the right to suspend or terminate your Account and refuse any and all current or future use of the Service, for any reason at any time.”

Who do these terms protect?

It seems to me that Nozbe’s terms of service have been written to protect the interests of apivision.com as the SaaS supplier, and not the customer.

These terms of service are not customer-friendly. There is no commitment to providing the service. It even sounds like my data can disappear at any time without any recourse.

I am sure that this was not the intention, but it is almost as if the terms had been written with the sole intention of scaring potential customers away.

Trust is the very first sales qualifier

In my recent post Why ISVs Need a SaaS Trust Architecture to Survive the Shift to SaaS I explained when you offer your application software via SaaS, building a trust relationship with your customers is the most important thing you must do.

I looked at Nozbe’s terms of service for a first impression to see whether or not they are giving trust the emphasis it deserves. I do not know apivision.com and I have no previous experience with their products or services. They therefore started with a trust level of zero from me as a potential customer.

Moving to a SaaS GTD solution might not be a big risk in overall terms, but the risk is too large for me to trust my data to Nozbe.

This is a shame as Nozbe might have been a good solution to my GTD needs.

The lack of any indication of a SaaS Trust Architecture means that I will never know how good Nozbe might have been. On the other hand, apivision.com has lost a qualified and motivated prospect at the very first stage of their sales funnel.

Let your competitors make Nozbe’s mistake!

apivision.com missed an opportunity to start building a trust relationship with me as a qualified prospect for their Nozbe GTD SaaS solution

The lack of a SaaS Trust Architecture means that all the time and effort that they have invested in building software or improving their back-end infrastructure are wasted investments. A little more thought on developing terms of service focused on building a trust relationship from the very first contact could have made all the difference.

Many of your future competitors will try to take the easy option and write terms of service like Nozbe that are solely for their benefit and not their customers. That is bad for them, but good for you.

Design your terms of services to focus on gaining and keeping your customer’s trust as part of your SaaS Trust Architecture. This will mean exposing yourself to new and unfamiliar risks. That is a core part of the new SaaS business model — get used to it.

You are not going to survive and profit from the shift to SaaS unless you can live with this reality. apivision.com does not yet seem to have learned this lesson.

Image: If you don’t trust your diving mate, your safety is a (potentially fatal) illusion. SaaS safety doesn’t mean having the best data centre or the right multi-tenant architecture. It’s a lot more simple than that: it’s only about trust.

If you are trapped underwater the Rule of Threes says you can survive 3 minutes without air. Your top priority is clear and simple: find air to breathe, and quickly.

What should your top priority be when rebuilding your ISV to survive and profit from the shift to SaaS? Reading press and analyst reports on SaaS you might think your top priority should be building a scaleable back-end platform. Or, maybe your priority should be to select the right rich-client development tool.

These are certainly important issues, but they are not your top priority. Your top priority in rebuilding your ISV is to create your SaaS Trust Architecture. It really is as clear and simple as that.

Why trust is critical for SaaS

The reasons are simple and pragmatic:

• Wthout trust, it does not matter how scaleable your back-end platform is.
• Without trust, it does not matter which ddevelopment tool you use for your rich-client.
• Without trust, it does not matter what high levels of customer service you claim to supply.
• Without trust, it does not matter how economical your per-seat subscription model is.

By shifting to SaaS you are asking your customers to make a massive change in the way your two companies interact with with each other. Your customer will be truly dependent on your ability to deliver what you promise. In a sense they are putting their life in your hands.

But our customers already trust us!

I am sure that they do. But this trust is for your current business relationship with your installable products. That is very different from what you should expect when offering your software as a service.

Your customers currently use your business application to run part of their business. They do not rely on your company on a day-to-day, hour-by-hour basis. With SaaS that all changes.

The stakes of the game become a lot higher with SaaS. You will be asking your customers to trust you with their data. And that is a big leap from the customer/ISV trust relationship you have at the moment.

The new relationship will require a completely new level of trust in you and your company.

The scope of your SaaS trust architecture

Your SaaS Trust Architecture must be at the heart of everything you do, including:

• Service level agreements
• Data protection and security
• System availability
• Disaster recovery
• New functionality
• Licensing and pricing
• Data portability
• Integration

Each technical and business decision impacts on trust. In each case you must take into account how your customer’s trust in you will change — positive or negative — as a result of each decision. And this is not just relevant to the decisions before the sale is made. You are moving to a recurring revenue model so you will need to keep proving yourself each and every day.

Just be looking at some typical service level agreements by companies offering SaaS solutions you get an immediate idea of how much trust to put in that company. In many cases the trust level is zero.

This is something that I will be looking at on a regular basis with reviews of selected service level agreements. By seeing how other people are getting this critical aspect of the SaaS business totally wrong you can avoid making their mistakes.

Trust is everybody’s responsibility

The number of interfaces between you and your customers increases with SaaS. This makes it everybody’s job to be aware of the “trust impact” that they can have on your customers.

You currently operate at arms-length from your customers and their running applications. With SaaS you are directly involved. Every move you make — every moment of every day — impacts your customer’s level of trust in you and your service.

One ill-considered email from your support team in reply to a customer’s question about system availability can destroy your investment in building and maintaining trust. Each and every member of your team must therefore fully understand the impact of what they do and say (or do not do, and do not say) will have on your customer’s perception of how trustworthy you are.

Remember: trust takes a long time to build, but no time at all to lose.

Do you trust your suppliers?

A big challenge that you will face in rebuilding your ISV business for SaaS is that you will have to offer your customers a higher level trust than you might currently have in some (or even all) of your own suppliers. This is a key aspect of your risk in offering a SaaS solution, and this is exactly of sort of risk that you have tried to avoid in the past.

A key issue that all ISVs have had to address in the past is the extent to which they can afford to be dependent on external suppliers. This issue often comes up in discussions about the use of development tools compared to doing everything in-house. I can certainly recall a lot of discussions with our application ISV customers when selling application development tools in my previous life.

As you move to SaaS you are going to have to face up to coping with supplier risk is a fact of life for all SaaS ISVs. While you might have been able to justify developing your own database abstraction layer (for example), you are not going to be able to develop all (or even most) of your SaaS platform yourself. You are going to be dependent on a lot of external suppliers, many of which are new players in the market.

Trust is a key part of your defensible position

Getting all of these moving parts to work together in a reliable manner that you can repackaged for your customers is a critical part of what it means to be an SaaS ISV. It is your job to come up with ways of abstracting the risk so that you can offer a higher level of service to your customers than you might get from your suppliers.

You have a big advantage compared to the new entrants who will be trying to steal your customer base with their new SaaS-only offerings:

• Your existing customers have an existing level of trust in you as a long-term supplier.
• Your potential customers have a certain amount of trust in you because other companies in the same field as them have clearly chosen to trust you in the past.

Your new competitors do not have either of these benefits. While they might have a lot of VC money to spend on high-end hardware, advertising or building the latest Web 2.0 client — what they do not have is any quick way of getting their potential customers to trust them with their critical data and applications.

This is where you are way ahead of the game. You have trust and can build on that as part of your defensible competitive position for your vertical niche in the emerging SaaS market.

All the rest is just technical detail.

Image: Rick Chapman, managing editor and publisher of Softletter, speaking at the Business of Software conference held in San Jose, California in October 2007.

You know the shift to SaaS is life-threatening for your future as an ISV — you are doing something about it and reading ISV Survival! Still, you will need to convince colleagues who have not understood the risk your ISV is facing from Software as a Service.

A good place to start is Rick Chapman’s presentation: The SaaS Tsunami: An Analysis of why and how Software as a Service is changing the market.

Rick Chapman, managing editor and publisher of Softletter, spoke at the 2007 Business of Software conference held in San Jose, California in October 2007. His slides and a video of his presentation are available from the Softletter website.

SaaS is not an issue — our product is special!

After a general introduction on why the earlier Application Service Provider (ASP) market exploded with the dot-com crash, Rick gets into his stride at slide 19 with the 3 lies that people tell themselves to justify in their minds why SaaS is not a risk for them:

1. Our products are too “core” to be replaced by SaaS equivalents.
2. SaaS is too monolithic — our products require extensive customization.
3. SaaS is not good enough — the desktop is too powerful and flexible — SaaS is too slow.

I am sure you have heard exactly these objections on more than one occasion.

The our product is special view is an especially risky way for people to think about SaaS. This comment tells you that they have not truly understood the life-threatening situation you (and they) are in.

If you hear anyone at your ISV claiming that SaaS does not matter then you know that you need to make clear (and fast) that, with respect to SaaS, your product is not special at all.

Trapped underwater? Find an air supply — quick!

As I mentioned in What Connects ISVs, SaaS and Survival?, the Rule of Threes helps you focus on what is really important in life-threatening situations.

Claiming SaaS does not matter because our product is special is like being trapped underwater and focusing on finding something to eat. If you are trapped underwater then you need an air supply — within 3 minutes — otherwise you are dead. Shelter, water or food are not the things you should be giving any thought to at all.

What this means is that you must redouble your efforts to ensure everyone in your organization really understands that SaaS impacts all areas of your business and that you need to start doing something about it. Now.

Everyone needs to understand the risk from SaaS

Rick’s presentation is a good introduction to some of the core thinking behind SaaS. You can use it as ammunition to convince some of your “SaaS doubters”:

• Ensure everyone is absolutely clear on exactly why SaaS is such a risk to your existing ISV business.
• Explain the concrete steps you are planning to take to survive and profit from the shift to SaaS.
• Explain about the Rule of Threes — in life-threatening situations focus on what is really important and do not get sidetracked by wishful thinking that SaaS is something that will go away.

Good luck! Let me know how you get on.

Image: In a dangerous world it’s vital to understand the risks and set your priorities accordingly. Survival experts teach: learn (and apply) the “Rule of Threes” and your chances of surviving a life-threatening situation go up. A lot!

Trapped underwater and no air to breathe? Lost in the mountains and no shelter for protection? Stranded in the desert and no water to drink? Stuck in a wasteland and no food to eat?

What should you do if you are in one of these life-threatening situations?

First thing: understand your situation and set priorities. This might seem obvious; sadly, the news regularly reminds us otherwise. People often set the wrong priority and the price they pay is their life.

Are there any rules to help you set your priorities in life-threatening situations?

Survival: The rule of threes

Yes, it turns out that there are such simple survival rules. The “Rule of Threes” helps you to focus and set your priorities.

These simple to remember rules remind you how long you can survive in life-threatening situations:

• You can survive 3 minutes without air
• You can survive 3 hours without shelter
• You can survive 3 days without water
• You can survive 3 weeks without food

Survival experts teach: learn (and apply) the Rule of Threes and your chances of surviving a life-threatening situation go up. A lot!

Applying the rule of threes to ISVs

When I read about the Rule of Threes it struck me as a good analogy for ISVs facing the life-threatening shift to SaaS. Maybe there is a “Rule of Threes for ISVs” that can help ISVs to set their priorities to survive and profit from the shift to SaaS?

I think there is a “Rule of Threes for ISVs”, and that is what this ISV Survival blog is about.