How Complex Can SaaS Offerings Get?

Feb 14, 2008 by

It’s common place to equate Software as a Service with CRM, HR, or other “business function” style implementations. Although these implementations are not simple by any means, they generally do not require the computational rigor of an offering that performs complex mathematical analysis or photorealistic 3D rendering. In fact, it’s rare to hear that a company is pursuing this sort of “non-traditional” SaaS offering.

A recent discussion across two blog posts (this one and this one) sparked an interesting discussion about the viability of the SaaS model in the computer assisted design (CAD) space. The discussion revolved around issues like data access and security, but an important takeaway is to highlight that discussions are cropping up regarding application types that were traditionally considered “desktop only”. We see people discussing CAD, and even Adobe talking about bringing Photoshop online.

It’s my opinion that almost any application can be brought online these days, and that making those applications work well is a problem whose solution is rooted in good software engineering. SaaS offerings need not be restricted to applications that serve only horizontal business functions, but can branch out into non-traditional verticals such as CAD. I would even go as far as saying that in many cases, online versions may “out feature” and “out value” desktop counterparts. Take CAD for exampe: can every architecture and design firm afford servers that can perform photorealistic rendering? Probably not, but you can bet that a SaaS provider along with a massive render farm can give that sort of value to anyone on earth.

Do you feel my take on this is too agressive? Is it too early for traditional “heavy” client offerings to move to the SaaS model?

 

read more

Defensively Architecting a SaaS Implementation

Feb 7, 2008 by

If you’re a SaaSBlogs regular, you’re probably a big fan of the SaaS delivery model. One thing you also probably know is that one of the downfalls of the delivery model stems from the fact that it increases overall cost of failure and cost of downtime since it moves usage from a decentralized (aka on-premise) delivery mechanism to a centralized one. Although this is a downfall, it’s not a good enough reason to avoid the model; SaaS’ pros significantly outweigh its cons. The value afforded by SaaS outweighs centralization issues. That doesn’t mean, however, that an ISV should ignore problems posed by centralization. After all, if architected poorly, downtime may affect all of your customers, which would in turn clog your support lines and negatively impact your growth rate. So what can an ISV do to alleviate the pitfalls of centralization? Focus on defensive architectures.

As a discipline, SaaS architecture can take lessons from ship building. Normally, small vessels (let’s say one that carries 8 passengers) have a single compartment hull; that is, the hull is a single volume of air designed to keep the vessel afloat. One strategy to move 4,000 people from port A to port B is to put them on 500 such small vessels. If a vessel were to hit an iceberg, it would most definitely sink since a hull breach would open that single compartment up to water logging. However, the problem would be localized and isolated, with a high degree of probability that the other 399 vessels will make it to port B without a problem. Consider this to be representative of the on-premise model.

Much like the on-premise model, however, this mechanism for moving people is grossly inefficient at best since it requires separate crew and supplies for each vessel. A more efficient way to move 4,000 people would be on one massive vessel, exploiting obvious economies. Despite any achieved economies, an ugly facet rears its head: a poorly engineered mega-vessel could lead to the deaths of all 4,000 aboard in one fell swoop! What happens if it hits an iceberg? Consider this to be representative of the SaaS model.

So back to the iceberg question: fortunately, engineers architect mega-vessels defensively; rather than a single compartment, single volume hull, mega vessels are divided into multiple airtight compartments (for example, the Titanic had 16). A hull breach may cause any single compartment to flood, but the system as a whole remains resilient. Any load borne by the breached compartment is implicitly offloaded to the remaining compartments of the hull, keeping all 4,000 passengers alive despite a massive system failure! This sort of defensive model is absolutely necessary in ship design, and is something that SaaS architects and engineers should adopt in their design approach. Your software now becomes a single, centralized heap that is “carrying” thousands of customers. Focus on compartmentalizing resources and supporting system failure, but try to keep any one compartment from being dedicated to some subset of your customers (i.e. when a compartment on a multi-compartment vessel is breached, some subset of the 4,000 passengers did not sink as a result!). Of course we all know how things turned out for the Titanic which confirms that if the breach is big enough it can still take down the entire system but the idea is to minimize the risk and realize all you can do is reduce the probability that an unforeseeable event will have significant negative impact.

 

read more

Enterprise SaaS != Web 2.0: A Quick Hosting Perspective

Sep 10, 2007 by

I like a good mystery just as much as the next guy, and this story’s got it all.  If you haven’t got the time or interest to read the whole forum thread, here’s the synopsis:  Jatol.com (no hyperlink provided because of said mystery), a notable web hosting company seemingly popular with development crowds has simply vanished.  Literally.  Websites down. Domain missing. Phones disconnected. Believe it or not, even the owner is missing

At this point, there’s not even a support number to call and Jatol.com users aren’t even able to retrieve their stored data or web site files. As I read further down the discussion chain, I started thinking about how awful it would be if I were running a web-based business in a situation like this – the mere thought of surmounting catastrophic shutdown such as this is mind boggling.

While it may seem obvious to some, this story specifically highlights a very important part of what enterprise SaaS ISVs should look for in managed services: providers that can assert serious service level agreements and back them with real ramifications.  For instance: transparent multi-tiered redundancy, consistent and thorough backups and archives, potentially even software and hardware escrow services (see ‘catastrophic shutdown’ above). The bottom line is that hobbyist devs hosting websites or even working applications with reliable hosting companies count downtime in minutes, while enterprise count downtime in thousands of dollars.

The tricky thing about SaaS is that it fundamentally requires the ISV to at least purport to be the ‘provider’ of software.  While hosting may be outsourced and ISVs become at least the ‘P’ in ‘MSP’, it is vitally important that the backing ‘MS’ be up to par.  If you’ve dealt with an MSP (without naming names) and had service level ‘experiences’, what are your thoughts on MSP preparedness for SaaS?  Are MSPs ready to host enterprise SaaS applications that generate the aggregate load of potentially millions of ISVs’ users?

[poll=6]

 

read more

Can the Fortune 500 Achieve Efficiency through Intra-enterprise SaaS?

Jul 4, 2007 by

SaaS is generally approached from the standpoint that a SaaS provider will write an application and sell it as a service to other businesses. This provides the many well known business driver benefits to those who use SaaS. Additionally, it is also well understood that the provider generates certain efficiencies via the centralization of the technical burden associated with the application. Is there another realm of SaaS applicability, however? In my opinion, absolutely!

Whenever I gauge the ‘size’ of a SaaS provider, I look to see how many subscribers they support – not customers, but actual individual users. Many SaaS providers are in the 5,000 user to 20,000 user range across hundreds of customers. While these numbers are not small, some Fortune 500 companies have more employees than this, spread across numerous subsidiaries. Furthermore, the Fortune 500 write a considerable amount of software for use by their employees, with some software (such as HR/Expense Reporting/Time Management apps) used by virtually every employee. Can SaaS help organize this scenario? From the technical/architectural standpoint – yes it can. If an enterprise were to write software for their employees & subsidiaries with a single instance, multi-tenant model in mind, they would undoubtedly be able to centralize and organize administration while being able to distribute functionality. That’s powerful and efficient.

Have you worked on any intra-enterprise SaaS applications? Who were your tenants – subsidiaries or departments? Did IT realize efficiencies through the model?

 PS: If you are in the U.S., have a happy and safe 4th!

 

read more

SaaS Ecosystems: Are They Valuable and To Whom?

Jan 11, 2007 by

At first glance, the concept of a SaaS ecosystem seems to provide value only for the end user, giving SaaS customers a map benevolently drawn by the divine cartographers of their SaaS/ecosystem providers to navigate the ever growing jungle of offerings and value propositions. But as the age old saying “Never judge a book by its cover” implies, take a look below the surface.

First, do ecosystems provide value to the end user? Absolutely. SaaS ecosystems, by nature, create a synergistic effect and positive sum game for the end user. The concept of the ecosystem allows for the exploitation of its participants to the benefit of the end user. For example, as an end user buying into a SaaS service with a budding ecosystem, I can take advantage of the tight integrations I’ll likely find between the ecosystem’s members, making for a smoother ride. Conversely, if I were to buy into a SaaS service A and a disparate SaaS service B, odds are that I won’t be able to exploit a relationship or integration between them as easily as I would in finding a reasonable B substitute within A’s ecosystem. Extrapolate this to all of your software purchases, and you can see that synergy unfold or disappear, depending on which poison you chose. There is definitely value in buying into an ecosystem, but is the ecosystem really a result of provider benevolence? Probably not.

Before I get into why providers extract value from ecosystems as well, let’s think about what SaaS has done to the end user’s ability to find substitute providers for a given service type. Prior to the advent of SaaS, an end user would purchase and implement an on-premise solution for an exorbitant amount of money, time, and effort. This placed the customer in a precarious strategic “stuck between a rock and a hard place” situation: if the software product proved to be worth less than what its cost was, finding a substitute was generally unreasonable since they would have to re-incur all of those exorbitant costs for the replacement. In essence, the on-premise model greatly reduced a customer’s replacement mobility which would generally correlate to a reduced customer flight risk for the vendor. Think of replacement mobility as the product of having substitute options coupled with your ability to leave your current software choice and flight risk as the risk of a SaaS provider losing a customer due to the customers replacement mobility. A reduced flight risk meant that even though the customer disliked the product, they would probably continue to invest in it by purchasing small upgrades, support, and customizations from the vendor. Obviously, the vendor liked this. SaaS, however, turned this model on its head. Assuming a customer can access their data, the cost of switching from one vendor to a substitute is much less pronounced than the on-premise model. This difference created a value gain (in green) for the customer and a value loss (in red) for the vendor when contrasting with the on-premise model.

(bigger)

SaaS vendors are aware of this, forcing them to place a large amount of focus on delivering quality functionality and service to reduce attrition rather than rely on the artificial retention dam created by the high cost of implementing on-premise. Although customers view this as fair, vendors (particularly those who used to sell on-premise) view this as sour grapes. The ecosystem, however, helps reallocate some of the customers large value gain back to the vendor. When a vendor deploys an ecosystem and populates it with value-added partners, it is providing the customer more value while also making it more difficult for the customer to leave in events of teetering dissatisfaction. A customer acting as an ecosystem consumer now has to ask “Can I find a substitute for the SaaS service and the value I’m deriving from the ecosystem.” Being a more difficult replacement proposition might force the customer to overlook some levels of dissatisfaction they may not have overlooked if they were not consuming from the ecosystem, thereby placing less onus on the vendor.

(bigger)

Does the ecosystem provide value to the vendor? Absolutely. The ecosystem can generally be considered a win-win, as long as the customer is aware that it will affect their replacement mobility. So how do you feel about ecosystems? Do you think they’re all hype, or actually add value to a SaaS offering or platform? If you’re a provider, do you see value in reducing attrition rates through a tactic like this?

 

read more