ISV Survival blog – Put trust first to win at SaaS

Taking a peek at what’s going on inside Amazon’s cloud

Andrew Biss — 2008-07-03T11:21:00+00:00

CloudStatus.com is a new service that peeks inside Amazon's cloud. It is great to see others entering the market and offering added insight in core cloud services.

It is important to know how reliable your cloud provider is. The SaaS community heavily criticized 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.

Rather than spending time and resources on building such a monitoring system yourself, Hyperic has launched CloudStatus.com. 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.

Join the conversation on the article “Taking a peek at what’s going on inside Amazon’s cloud”.

Tagged with: SaaS Dashboards

“Taking a peek at what’s going on inside Amazon’s cloud” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

paasTalk: Platform as a Service news for European ISVs

Andrew Biss — 2008-04-10T10:28:01+00:00

PaaS is a big change for ISVs who traditionally mistrust "all in one" solutions. Even so, PaaS is a strategic change in how successful SaaS ISVs will build and deploy solutions for their niche. The paasTalk blog delivers independent news and views on this important development, with an emphasis on the Europe-specific challenges facing ISVs moving to PaaS.

Things have been quiet here on ISV Survival as I have been launching paasTalk, my second blog. The slogan for paasTalk is “Platform as a Service news for European ISVs”.

The new paasTalk blog is for European ISVs and helps them to evaluate, select and implement Platform as a Service to build and deploy the next wave of SaaS solutions for their vertical niche.

paasTalk delivers the latest independent news and views on PaaS, with an emphasis on the cultural, legal, financial and infrastructure challenges of PaaS for European ISVs.

paasTalk will be more technical than ISV Survival, but will not be getting into bits and bytes. The target audience is ISV development managers and those responsible for making the core platform and technology decisions for the move to SaaS.

The first posts on paasTalk

To give you an idea of the sort of posts which will be appearing on paasTalk I have included links below to the first three paasTalk posts. Please come over to paasTalk and see what is going on. I look forward to seeing you there!

Could the Amazon EC2 cloud computing platform squeeze the profits from SaaS applications?

You need to build a (reliable) SaaS application from a portfolio of (unreliable) platform services–the price of which you cannot control. To survive you must ensure your application workload is never locked into a single utility supplier. A workload that you can segment and easily relocate from one utility to another gives you the credible threat you need to establish negotiating power with your CPU service provider(s).

Why hiding behind abstraction is not enough for SaaS applications

For decades on-premise ISVs have successfully hid behind abstraction. It was, and continues to be, an excellent way to manage technology uncertainty and implementation differences. SaaS ISVs have nowhere to hide. Building reliable SaaS applications from inherently non-reliable services demands a fault-tolerant approach. Abstraction just doesn’t cut it any more.

If you think SaaS solves all your platform troubles then think again!

ISVs have invested massive resources over the years to abstract their applications away from the underlying platform. This was required as every on-premise customer had a (slightly) different infrastructure. SaaS solves this problem once and for all with respect to the customer’s infrastructure. With SaaS the application is only installed once, and the ISV gets to choose the platform. Even so, there are still hard choices to be made–the exact same choices ISVs were facing 25 years ago.

Join the conversation on the article “paasTalk: Platform as a Service news for European ISVs”.

Tagged with: Announcement

“paasTalk: Platform as a Service news for European ISVs” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

ISVs use widgets to keep subscribers in touch with SaaS service status

Andrew Biss — 2008-02-25T22:39:00+00:00

Desktop gadgets and web widgets are popping up all over the place. These mini apps are ideal for ISVs to give subscribers real-time status updates for their SaaS services. They can also reveal key data and events.

Many subscribers extend their desktop using gadget or widgets. These mini apps from NetVibes, Google Desktop, Google Widgets, Microsoft Gadgets and Yahoo Widgets look good and can do a lot. There are thousands of free widgets to download, with many more to come.

Cross-platform support for Windows, Mac and Linux with tools such as Yahoo’s Widget Engine, Adobe’s Flash-based AIR and Microsoft’s Silverlight make it easy to build these widgets. They run outside of the classic web browser and can be placed as needed. Just park a widget where you can keep an eye on it. if you want, you can turn on sounds and hear status changes as they happen.

You can easily tap into this widget wave. Give your SaaS subscribers a free dynamic widget to show the live status of your SaaS service. Your subscribers get a good looking graphic they can put where they want. It is easy for your subscribers to keep an eye on your service status. They do not have to visit your special dashboard site.

Start with a simple service status widget

You can make a good start with a simple widget which shows the live status of your SaaS service.

Your subscribers benefit from real-time status updates. They do not have to keep the browser open or visit a specific page.

Where you get the status data depends on what you have easy access to. This could be from your own dashboard, your status RSS feed, or even your 3rd party uptime monitor.

Expose key data and events

Your next step is to expose selected data and events to your subscribers with a custom widget. I am sure there are key events and data your SaaS subscribers would like to follow.

An example is the “Opportunity Knocks” widget from Appirio. This connects to your Salesforce.com account and gives real-time event updates, such as when a deal closes. Using this widget it is easy to see what is going on.

It is easy for you to make your live service status visible with a widget or gadget. It shows you have trust in your service levels. This is vital for building trust, and trust is the most critical part of SaaS. So, why not get someone working on a simple status widget today?

If you have a widget or gadget that shows your live SaaS service status then please let me know via the comments. I would also like to hear about other widgets from SaaS ISVs that expose data and events.

Join the conversation on the survival tip “ISVs use widgets to keep subscribers in touch with SaaS service status”.

Tagged with: SaaS Dashboards

“ISVs use widgets to keep subscribers in touch with SaaS service status” is a survival tip from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

Survey reveals 10/10 SaaS ISVs hide live service status on their home page

Andrew Biss — 2008-02-25T12:35:00+00:00

My survey of 10 SaaS ISVs reveals that none show live service status on their home page. Add your live status to build trust and stand out from your SaaS competitors.

Your SaaS subscribers expect you to make your live service status easy to find. If you are not open and honest on this point, then you take the risk your subscribers will think you have something to hide.

Trust is critical to winning at SaaS. Adding your live status to your Web site home page is a quick and easy way to build trust. Why then do so few SaaS ISVs show their live service status? Do they have something to hide?

Searching for status

I wanted to see if SaaS ISVs have taken this simple step. Do they show their live service status on their Web site home page?

I expected to visit each home page and see the live service status in an obvious place on the page. Maybe a simple graphic with a “System OK” tick or traffic light. I also expected to find an obvious link to a detailed dashboard.

I only wanted to look at the home page and not dashboards at special URLs. For example, trust.salesforce.com and status.netsuite.com are good, but can subscribers easily find then from the home page?

The 10 SaaS ISVs

In my non-scientific survey I looked at these 10 SaaS ISVs:

Cornerstone OnDemand—Talent and performance management
Eloqua—Demand creation and marketing automation
Ketera—Spend management and procurement
Klir—IT analytics
NetSuite—Integrated system for business management
Oco—Business intelligence
Salesforce.com—Customer relationship management
SuccessFactors—Employee performance management
QL2—Market intelligence
QuickArrow—Professional services automation

I was surprised that none of them showed live service status on their home page! They also did not find link to their dashboard (assuming, that is, they have one).

Live status builds trust

Do not make the same mistake as these 10 SaaS ISVs.

Your current and future SaaS subscribers want you to be proud of your live status. You are wasting a great opportunity if you hide your live status in a deep link (or worse, behind a login dialog).

Your live service status is a valuable asset, so add it to your Web site home page. While you are at it, also add a clear link to your status dashboard. Your SaaS competitors are missing a trick here. It should not be hard to show your live status. It will help you build trust, which is the most critical part of SaaS.

I would like to hear from someone at the 10 SaaS ISVs I surveyed to hear their view on this. Why did you decide to not include your live status? Please let us know in the comments.

For the others: if you show your live status on your Web site home page then well done! Please share this with other readers and add a link to your Web site in the comments.

Join the conversation on the survival tip “Survey reveals 10/10 SaaS ISVs hide live service status on their home page”.

Tagged with: SaaS Dashboards

“Survey reveals 10/10 SaaS ISVs hide live service status on their home page” is a survival tip from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

What SaaS ISVs can learn about trust from a 300-year-old Japanese sweet company

Andrew Biss — 2008-02-22T14:26:00+00:00

The Japanese public were shocked that a 300-year-old sweet maker sold frozen sweets. SaaS ISVs can appoint a "Chief Trust Officer" to show they do not take trust for granted.

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). They said they made their sweets fresh each day. Any sweets not sold that day were 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.

Join the conversation on the article “What SaaS ISVs can learn about trust from a 300-year-old Japanese sweet company”.

Tagged with: SaaS Trust Architecture

“What SaaS ISVs can learn about trust from a 300-year-old Japanese sweet company” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

99.999% Hosting uptime SLAs do not matter to SaaS subscribers

Andrew Biss — 2008-02-20T15:59:00+00:00

SaaS hosting uptime does not matter if SaaS subscribers cannot login. B2B ISVs will pay with critical trust if they fail to talk to subscribers, even for faults not under their direct control.

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?

Join the conversation on the article “99.999% Hosting uptime SLAs do not matter to SaaS subscribers”.

Tagged with: SaaS Uptime

“99.999% Hosting uptime SLAs do not matter to SaaS subscribers” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

4 Examples help B2B ISVs improve SaaS live service status dashboards

Andrew Biss — 2008-02-17T17:45:00+00:00

B2B ISVs must have a live service status dashboard to keep their SaaS subscribers informed. Dashboards from DoubleClick, Intuit QuickBase, Salesforce.com and OpenDNS show some good ideas to adopt (and some bad ones to avoid).

My last post was about learning from Friday’s Amazon S3 downtime. The main point is that you must keep your subscribers informed. A live service status dashboard shows the key data your subscribers need.

Amazon did not have this for S3. Subscribers were left to guess if there was a problem, and when it would be fixed. They have now said they will release a live service status dashboard soon.

Lets have a quick look at some live service dashboards. Look what others are doing to get ideas to improve your own dashboard.

DoubleClick

DoubleClick has a live service status dashboard for their ad network. This is the DART dashboard for their campaign platform. We can see the number of ads, the number of ads displayed and ad serving speed.

The main customers of DART are ad agencies and media firms. This might explain the dashboard design. For many B2B ISVs this type of design could be see as too “marketing”. The focus must be on the status and not the graphic design of the dashboard.

The second example shows real-time monitors for the DoubleClick network from Gomez, Inc. The user first sees a world map. This shows the areas serviced by DoubleClick. The user then clicks on an area (USA here). The user now sees the number of monitors running and the current response times for that area.

I am also not sure that Flash is a good idea for a live service status dashboard. I had problems accessing the site from Firefox. Worked OK from IE, Safari and Opera.

Intuit QuickBase

QuickBase is a set of workgroup tools to manage projects, sales etc. The QuickBase live service status dashboard is much simpler than DoubleClick’s. The key data can be taken in at a glance.

A nice extra is to show planned downtime. The right side shows service status over the past 30 days. Each planned and unplanned event is explained.

If you do not yet have a live status dashboard then this is a good place to start. Do not forget to add an RSS feed, though.

Salesforce.com

Salesforce.com added the Trust live service status dashboard in 2006. Much like Amazon S3 today, Trust was a response to major downtime at the end of 2005 and the start of 2006. The status of each instance is clearly shown, plus details of the past 30 days. Clicking on a non-green status icon pops up details of the problem and the fix.

This dashboard has more detail than QuickBase. Again, there is no RSS feed of service status changes.

OpenDNS

The final example in this quick roundup is from OpenDNS, a free DNS resolution service. Their live service status dashboard shows what can be done. Current status is shown at the top of the page. Details from the last 30 days are in the body of the page. The status icons are clearly explained.

Clicking a non-green status icon pops up details of the problem. The wording is friendlier than on Salesforce.com. They are even signed by a real person, giving a more honest and open feel. There is a graphic of service use in the top right.

If OpenDNS is down the dashboard might not be found. A bookmark of the IP address helps for this case. Plus points for the clear link to a RSS feed to get service status updates.

Improve your dashboard

There are a number of ways to design your dashboard. I do not suggest you follow the design used by DoubleClick. The very clear and clear page from OpenDNS is a better model in my view. It shows the key data the users need. The downtime text is clear. The RSS feed is a strong plus point.

Your live service status dashboard must give a honest view of your SaaS system. Resist not showing all problems or downtime. Salesforce.com customers have reported downtime which the firm denied. This does not look good in the press and on blogs. You must be 100% open and honest in your dashboard. OpenDNS sign their explanation pop-ups. This builds trust. Follow this good idea on your dashboard.

Please share

I hope you liked this first quick look at some live service status dashboards and found some ideas here to improve your own dashboard. Please share your ideas to improve this vital aspect of SaaS for all B2B ISVs. Add a link to your dashboard in the comments.

Join the conversation on the survival tip “4 Examples help B2B ISVs improve SaaS live service status dashboards”.

Tagged with: SaaS Dashboards

“4 Examples help B2B ISVs improve SaaS live service status dashboards” is a survival tip from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

Lessons from the Amazon S3 crash—ISVs must keep SaaS subscribers fully informed

Andrew Biss — 2008-02-16T15:14:00+00:00

Friday's Amazon S3 crash showed how vital it is to talk to users. ISVs must plan for downtime and actively keep users informed in times of trouble.

Early on Friday the Amazon S3 cloud storage service crashed in a big way. Lots of web sites, some very well known, could not access their data.

Amazon quickly found and fixed the problem. It was not a hardware or network problem as many assumed. Amazon said that the issue was a web service at one of their 3 data centers. The service checks all user requests and SSL links. It was slowed by a sudden peak in SSL requests. Non-SSL requests were blocked. The whole of Amazon S3 stopped.

During and after the problem customers talked about the lack of feedback from Amazon. For the future Amazon will release a service health dashboard. This is a good step and is required.

How would you have responded in the same situation?

You can learn from Amazon’s mistake. Take a look at how this fault was covered by blogs and in the press. How would a problem like this affect your SaaS platform? What will you do when it occurs (and it will, sooner or later)?

Keeping your subscribers informed

Many ISVs now rely on Amazon S3 and EC2 for their SaaS platform. Not all of these ISVs were prepared for a failure in Amazon S3.

Friday’s fault showed how vital it is to inform your subscribers when things go wrong. Amazon did not do this and their customers were upset. In a chain reaction, subscribers to the ISVs sites were also very upset.

What process do you have for when a similar problem occurs on your SaaS platform?

Do you have monitors to report a change in service status at your back-end suppliers?
Do you use a DNS redirect to show your subscribers a status page when the system is down?
Do you have a way to inform logged-in subscribers of the problem?
Do you run your status and monitoring on a totally independent platform to your main SaaS platform?
Do you provide status information in human and machine readable forms?
Do you make it easy for your subscribers to bring your status information into their existing management and support systems?
Do you have a way to tell your subscribers the system is up again?

Its your problem now

With on-premise software you did not need to worry about all this. These were issues for customers and their IT groups to manage. This all changes with SaaS. You are now offering a service and not just the software. This is now your problem, not theirs.

Do not wait until your SaaS platform crashes. Amazon did not get away with not talking to its customers. Neither can you. Now is the time to plan and prepare!

Were you affected by Friday’s Amazon S3 downtime? If so, how did you tell your subscribers? How did you keep them up to date? How did they react to the downtime?

Join the conversation on the survival tip “Lessons from the Amazon S3 crash—ISVs must keep SaaS subscribers fully informed”.

Tagged with: SaaS Trust Architecture

“Lessons from the Amazon S3 crash—ISVs must keep SaaS subscribers fully informed” is a survival tip from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

Bessemer CEO summit presents 10 laws of SaaS, ignores SLAs?

Andrew Biss — 2008-02-15T15:37:00+00:00

CEOs from leading SaaS ISVs improved their golf at a recent VC event. Their time would have been better spent improving their SLAs.

In his recent blog post, Philippe Botteri from Bessemer Venture Partners lists the “10 Laws of SaaS” from their recent invite-only event for CxOs. I agree with 9 of the 10 laws, but disagree with law 6:

6. One Datacenter. Invest early in backup and disaster recovery, but stick to one data center, at least until well after IPO.

How many data centers you have does not matter. What matters is your SLA, and there is no mention of service level agreements in the “10 Laws of SaaS”.

I think this focus on the number of data centers is wrong. Customers only want to know the terms of your SLA, and whether you can meet those terms when a problem occurs.

Your SLA: What you do when things go wrong

ISVs must answer hard questions on uptime and security from new SaaS customers. B2C ISVs with Web 2.0 sites might be able to avoid these for a while. B2B ISVs cannot.

A tough and fair SLA is vital to your success as an SaaS ISV. You must focus on your SLA from day 1. You will ask customers to trust you, your software and your systems. If your SLA is not credible (or worse, does not even exist), you will not make any sales.

Your SLA is vital to your success in a way your support offer was not with on-premise sales. Any SaaS problem is seen by all your subscribers. You have to react, and you have to react now. You do not have time to stop and think, just act. You have to do your thinking when you write your SLA, not when a problem turns up.

CEOs: Spend less time on golf and more on your SLA

Did you handle the problem well? The answer is up to your subscribers, and not you. What they expect is in your SLA. You might do a great job of fire-fighting, but if you do not do what your subscribers expect then you have a big problem.

Do not spend your time worrying about keeping your hunters and your farmers separate. Instead, make your CEO your SLA champion!

Your SLA is at the heart of your SaaS business. Ignore it and you will not be going to many invite-only events at Golf and Country Clubs in Silicon Valley.

Join the conversation on the survival tip “Bessemer CEO summit presents 10 laws of SaaS, ignores SLAs?”.

Tagged with: SaaS SLA

“Bessemer CEO summit presents 10 laws of SaaS, ignores SLAs?” is a survival tip from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

Can your ISV survive paying real cash for SaaS downtime?

Andrew Biss — 2008-02-07T17:39:00+00:00

We will look back and laugh at the time SaaS ISVs got away with no or very weak SLAs. SaaS will improve if ISVs pay real cash to customers 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 24x7 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 Web site 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 centers 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.

Join the conversation on the article “Can your ISV survive paying real cash for SaaS downtime?”.

Tagged with: SaaS SLA

“Can your ISV survive paying real cash for SaaS downtime?” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

ISVs will always take the blame for SaaS platform downtime

Andrew Biss — 2008-01-07T22:06:00+00:00

ISVs must isolate their applications from today's SaaS platforms to benefit from the improved SaaS platforms expected in the future.

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

I have 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 “production” user of Amazon Web Services, 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 center. 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 centers 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?

Standardized 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.

Join the conversation on the article “ISVs will always take the blame for SaaS platform downtime”.

Tagged with: SaaS Platforms

“ISVs will always take the blame for SaaS platform downtime” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2008 ISVfocus.com Limited. Some rights reserved.

Customers using Web 2.0 applications are driving expectations for SaaS ISVs

Andrew Biss — 2007-12-31T17:59:00+00:00

Web 2.0 teaches customers what to expect from web-based applications. ISVs are under increasing pressure to shift their applications to SaaS.

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 web sites. 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…

Join the conversation on the article “Customers using Web 2.0 applications are driving expectations for SaaS ISVs”.

Tagged with: Installable Software, Web-Based Applications

“Customers using Web 2.0 applications are driving expectations for SaaS ISVs” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2007 ISVfocus.com Limited. Some rights reserved.

Nozbe: SaaS GTD solution fails to build trust relationship with terms of service

Andrew Biss — 2007-12-26T20:34:00+00:00

Your terms of service must build a trust relationship with your customers from day 1, otherwise all your other investments are wasted.

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 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 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.”

“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 refuse service to anyone 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 learnt this lesson.

Join the conversation on the article “Nozbe: SaaS GTD solution fails to build trust relationship with terms of service”.

Tagged with: SaaS Anti-Patterns, SaaS Trust Architecture

“Nozbe: SaaS GTD solution fails to build trust relationship with terms of service” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2007 ISVfocus.com Limited. Some rights reserved.

Why ISVs need a SaaS trust architecture to survive the shift to SaaS

Andrew Biss — 2007-12-24T14:32:00+00:00

Creating a SaaS Trust Architecture is your top priority, because if your SaaS customers do not trust you then nothing else matters.

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 scalable 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:

Without trust, it does not matter how scalable your back-end platform is.
Without trust, it does not matter which development 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.

Join the conversation on the article “Why ISVs need a SaaS trust architecture to survive the shift to SaaS”.

Tagged with: SaaS Trust Architecture

“Why ISVs need a SaaS trust architecture to survive the shift to SaaS” is an article from ISV Survival. Please visit the site for more SaaS news, or subscribe to the RSS feed. Copyright © 2007 ISVfocus.com Limited. Some rights reserved.