SaaS Adoption’s Secret Weapon: Hosting Providers

Feb 4, 2008 by

It’s common place to discuss SaaS adoption as being driven by either an ISVs need to remain competitive or tackle new markets, or by customer demand to move responsibility away from internal IT to an outsourced provider. I support this as being very true, and we can thank these two constituents as being the driving force behind recent adoption. But is that all of the muscle that the SaaS movement has? Absolutely not.

Two constituents that care the most, and bring a lot of strength to the table, are enablement companies like Apprenda (our company), and application hosters (not really a ‘word’ but we’ll make it part of the post’s vernacular). Hosting companies/managed application providers are often overlooked or underplayed when discussing SaaS. Generally, the world of hosting has become a collection of relatively bland offerings with focus on “old style” services (although there are atypical cases). Most hosters are looking for a new value proposition that can move them out of a low margin commodity and back into the lime light. Building a business around SaaS alleviates the “low margin” problem and if hosters spend more time and money taking SaaS more seriously, they may become SaaS’ next champion. The more ISVs and customers they can attract, the more they can extract from this high value market.

I don’t believe SaaS adoption is set to halt by any means. In reality, I think there is still plenty of room for adoption via a collective championing of the delivery model by hosters who are looking to leverage their multi-million dollar infrastructure investments and pump up that good ‘ole revenue dollars/deployed infrastructure ratio!

Do you think that hosters can play a larger role in driving adoption? Do you see the next stage of SaaS innovation coming from hosters?

 

read more

The Right Tools for the Job

May 29, 2007 by

Are today’s SaaS enablement technologies robust enough to support business to business SaaS?  It’s a question I ask myself everytime I am introduced to a new ‘mashup engine’ or ‘online SaaS IDE’.  Granted, there are some very impressive products out there right now, Bungee Labs’ BungeeConnect and CogHead for example.  But initial impressions aside – are these whole product enablement environments robust enough to support extremely high levels of customization? Multi-tiered integration? Legacy integration? Complex computation and data types, and the myriad other requirements of the world’s most powerful business software? Even Salesforce’s proprietary Apex language born from Java seems a bit limiting in terms of programming expressiveness.  Or so I’ve heard.

CogHead made a statement in their early advertising that has stuck with me for awhile now – they said [paraphrasing] that “CogHead wasn’t designed for computational fluid dynamics calculations”, instead spotlighting ease of use for the business individual. The idea: an environment to quickly build business process applications, and it’s so easy that anybody in your business can do it.

The problem I have is not with the ingenuity or inventiveness of these types of environments. I think there is a ton of very cool, and applicable, things that can be done with them.  But I feel they alienate one crowd that, well, we owe pretty much everything to – software developers and engineers.  Those that have been schooled and trained in the complex sciences of computer programming and application engineering.  Believe it or not, but these folks are masters of an art – because there is a significant amount of expressiveness that goes into architecting an application, writing code, and optimizing it.  Furthermore, business to business SaaS includes applications and services that fundamentally require a powerful computational platform and languages expressive enough to harness the power of that platform.  I spoke with a vendor the other day who is looking for the right tools to develop an online service that provides genomic computation.  Yes, that’s right – genome sequencing for researchers, on demand.  

Some of the feedback I’ve read and heard from developers who’ve gotten their hands on languages such as Apex leads me to believe that developers’ hands are tied – even if they stretched the technology to its limits there’d be so much more they’d want to do with it that it’s almost not worth their time.  They’ve spent years honing skills in the .NET languages, in Java, PHP, Ruby, in name your favorite programming language – and now they’re being handed Javascript-based online IDEs and proprietary languages and told to deliver enterprise SaaS applications.  They’re being told by managers to port existing client\server code to an on-demand architecture using tools that simply don’t match up.

The tools exist, and developers have been using them for years.  They’re experts.  Perhaps SaaS enablers should focus on bringing the existing developer toolbet to the SaaS world, instead of enabling the rest of the business world around them with brand-spanking new tools that limit and eventually alienate developers.  Frankly, I think the novelty of so-easy-your-manager-could-do-it development tools will eventually wear off and the business world will turn back to developers looking for programmatic magic.  But, that’s a whole other post for another time.

The point is, handing an enterprise software developer some of these enablement tools and asking for a business-to-business SaaS application is like handing Mario Batali an EasyBake™ oven and asking for a six-course Italian dinner.  No matter the amount of genius and talent involved, there’s only so much you can do with a 100-watt lightbulb.

 

 

read more

It Costs More to Be a SaaS Company. How Platforms May Fix That.

Jan 25, 2007 by

Yesterday, Will Price of Hummer Winblad wrote a terrific quantitative analysis comparing the upfront funding needs of SaaS vendors, or application providers, with the funding needs of traditional software firms. In case there was any doubt, his data shows that funding a SaaS endeavor requires substantially more money – on the order of 3.65 times more capital, in fact. His article is titled “The Economics of SaaS: We Need a Platform.”

Mr. Price’s funding breakdown consists of data for publicly traded software companies in both the enterprise client/server space, and those that have reached IPO with primary SaaS offerings. His numbers add substantive clout to the prevailing, though often questioned, thought that starting a SaaS company or moving existing business to the SaaS model costs more than the traditional client/server model. Mr. Price deduces that the way to reduce SaaS development costs is to speed up development time – to get to revenue quicker. But how? Well, it’s no surprise that Mr. Price provides the platform as the answer. Solving the time to market and infrastructure overhead hurdles for SaaS vendors is what us platform developers refer to as ‘The Problem’.

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

The Evolution of SaaS

Jan 8, 2007 by

Regardless of whether one believes that Darwinian evolution is how the species of this planet came to be, most will agree that the premise and underlying structure of evolution is both powerful and to some degree measurable in the real world. One of the most important things to ask IS “Why study history and why attempt to understand the underpinnings of our origins?” The answer, in my opinion, is simple: we study history to mitigate risk in the present and future, and build on a foundation of measurable results. That said, understanding how SaaS came to be, and where it’s heading with the powerful concepts of the SaaS Platform and ecosystem. This complements one of my earlier posts regarding the categorization of SaaS, and I’m definitely looking for input as I view the unfolding of these definitions a communal effort.

I find that diagrams do a much better job at explaining concepts rather than multiple paragraphs of banter. As a result, I’ve put together a brief overview of how I see the evolution of SaaS unfolding. The evolutionary variable (measured over time) is how SaaS was/is implemented:

(bigger)

The timeline focuses how SaaS (On Demand) implementations have changed. Generally, implementation can be hidden from a user, but that’s not always the case. For example, a “streamed” application like Office 2007, while it would fall under the category On Demand, is far different than say Zoho’s web office, both from the implementation standpoint and the viewpoint of the end user. Looking at the timeline, however, one underlying theme is present: overtime, implementations converge to abstraction. We see this all the time in the IT industry, whether it’s the operating system abstracting the hardware layer (HAL), development languages such as C# and Java abstracting away some of the more difficult concepts such as memory management, our industry noticeably thrives on simplifying through abstraction. This is how we become more efficient, less vulnerable; abstraction helps us become a well-oiled machine and helps the end user see more and more value. With this abstraction also comes the ability to harness it as a common ground through concepts such as valuable SaaS ecosystems. Prior to platform and platform-esque implementations, the concept of the ecosystem would have been overly difficult to introduce and implement correctly. The evolution of SaaS is continually refining the various SaaS species to be more in-tune with the long term, ensuring that it’s here to survive the long haul (short of a catastrophic asteroid landing, of course).

SaaS is continually pushing towards a day where both use and development of SaaS applications is easier. Nonetheless, many of the early SaaS successes (Salesforce.com, WebEx, RightNow, etc.) were the precursors to this abstraction, which is something that the industry should value since they laid the groundwork for moving forward and turning SaaS into a viable delivery mechanism. Now, these same industry leaders are trying to move into a more abstract space with their own product-centric platform introductions. While they may succeed, history has shown us that it’s not the oldest species that survives, but the smartest, and these companies are going to face a slew of new SaaS platform players. These SaaS players are looking to enable the next-generation of applications for the enterprise, and hope to carry the genetics of SaaS but leave those early species behind with the dinosaurs.

read more