What to Look For in an On Demand Platform (aka SaaS Platform)

Nov 27, 2006 by

The clamor and buzz surrounding on-demand platforms for SaaS has been growing steadily. I recently wrote an article on Marc Benioff’s latest platform position. In the video interview I reference, Mr. Benioff highlights some key, defining aspects of platforms. Although in the article I discuss a prevailing ambiguity in Benioff’s vision, I must say that I agree with most of his statements regarding platforms. I was recently reading an excellent post by Phil Wainewright that summarized panel discussions at the SIIA OnDemand Summit. In the summary, Mr. Wainewright discusses how most of the panelists congregated around the SaaS platform & ecosystem campfire. I realize that the discussions were high level, but the topic coupled with Mr. Benioff’s observations prompted me to think about the next step: what are some of the traits that *might* (notice the * for ‘proceeding with caution’) define a successful platform in the future. I came up with the following, in no particular order:

  1. Multi-tenancy – A platform like Apex (and most likely WebEx Connect) strive to define multi-tenancy, and generally single instance, for their constituent applications. The importance resides in the notion that multi-tenancy is one of the defining aspects of efficient SaaS in general.

  2. Security – Any platform worth its salt will make sure that the applications it contains are secure from internal/external attacks as well as purposeful/non-purposeful malicious code.
  3. Application Portability – The concept that one can build an application, of which some portion of it is portable, will be important. The idea that a lock-in platform will succeed is a stretch.

  4. “Mash-Up”
    & Connectivity Capability – Although I hate the word “mash up”, I love the concept and practice. A platform will be responsible for certain levels of connectivity with the outside world, or for that matter, with other platforms. This is where “Web 2.0″ comes into the picture, and where successful platforms will thrive.

  5. EcoSystem Offering – The applications and ecosystem offered under a platform’s umbrella will provide a reason for end users to come back. The platform’s ecosystem will be important to its long term survival.

  6. Reliability – A platform is a foundational construct. What happens to structures on a shaky foundation? This.

  7. Design Stability – Any dependency between a platform and its applications must be stable. Platforms with frequent design changes requiring application modifications will most likely fail. Engineers won’t put up with this sort of stuff and will look for alternatives (assuming that property 3 is available to some degree).

I don’t consider this list exhaustive by any means, but I wanted to start the topic off. Any ideas on what else should be there? If so, leave a comment and I’ll reply/incorporate it into a later post.

read more

Related Posts

Tags

Share This

Marc Benioff, Please Stop Confusing Me

Nov 15, 2006 by

Salesforce.com has definitely reached powerhouse status, and is one of the main proponents of SaaS. For this, I thank them and really see them as a driving force. That aside, what is going on in Marc Benioff’s head? I wrote an article a while back about Salesforce.com using Apex as a lock-in strategy, which spilled over into a ZDNet blog article, and was vehemently opposed by Salesforce.com employees in both articles comments, with arguments ranging from there is no lock-in to there is no way around lock-in and expecting application portability is unreasonable.

While I respect the various positions on the topic, it seems as if there is a point of contention between Salesforce.com’s offerings and their CEO/Thought Leader’s vision. Dan Farber of ZD Net recently interviewed Benioff at the Web 2.0 conference. Here, Benioff touts the platform as the next evolution of the web & SaaS, where, to paraphrase Mr. Benioff, one will be able to move data and code from one platform to the other, and where the platforms ability to deliver quality service and value will define whether or not an application remains there or moves elsewhere…how is that anything like Apex and AppExchange? I’m quite certain no one will run Apex code other than Salesforce.com, at least not now. Either Mr. Benioff is drinking someone else’s Kool Aid, or we can expect Apex to become some sort of open standard. In all seriousness, am I missing something here?

read more

Related Posts

Tags

Share This

Bacon Bits & SaaS: Imitatations are Tasty, But the Real Thing is Better

Nov 1, 2006 by

Whenever I decide to go all-out on a baked potato, I have a few key requirements: sour cream, chives, shredded cheese, and bacon bits. Many people are content with imitation bacon, or eat it for health/religious reasons, but not me. I like the taste of the real thing. Without it, frankly, I can’t eat my potato. Let me correct myself, I can eat it, but I don’t feel like I’m really eating a true baked potato; I’m not getting the value I should be getting out of it because I’m experiencing a degradation in my realized utility (how’s that for mixing bacon, potatoes, and economics?).

The importance of this is in the recognition of true vs. imitation SaaS. I recently read two great articles: one by John Martin for Supply & Demand Chain Executive and another by Brain Reed of the Business Certainty blog (the latter provides a compound summary of the topic, including Martin’s article as a source). I wanted to write on the topic to reinforce the difference between true and imitation SaaS and highlight the importance of how real is better than imitation in terms of utility and value realized by the end users and SaaS vendors themselves. I find that SaaS is still many times confused with ASP, or that SaaS is not understood from the multi-tenant, single instance angle (which IMHO is a defining property of true SaaS).

So first, what is “true SaaS” and why have I so cleverly analogued (made up word) it to “real bacon bits”? Well, true SaaS is defined by the technical merits and architecture of a purported SaaS application. From the architectural point of view, true software as a service, as described by Martin, is one where vendors use “…the same production environment to support multiple customers.” While this is absolutely correct, let’s further that qualification by using the SaaS cliché of “single instance, multi-tenant” which equates to refactoring that sentence as “…a single production environment to support all customers.” Moreover, a true SaaS application must maintain an innate & acute awareness of the notion of a user at all times, isolating execution paths and data from one user to the other while being able to recognize the user “owning” the current execution path. Awareness is what will open the path to per tenant customization. Combining this with the previous notion of single instance, all designed via the SOA paradigm, we have a very powerful concept that transcends the technological “cool” factor and directly attacks the demons that exist to choke the life out of your bottom line. Why is the purity of architecture so important to bolstering the SaaS value drivers and why is it so important to business? Simple. Efficiency, efficiency, efficiency. While retailing popularized “location, location, location”, I think SaaS will find efficiency equally important (at least enough to repeat three times). SaaS, as a model, intends to build economies of scale by consolidating much of the grunt work associated with maintaining an application, while also outsourcing the hosting infrastructure, improving quality of service, and a slew of other benefits. In order to deliver value (real, tangible, sweet smelling ROI), however, vendors must strive for maximum efficiency so that savings can be passed on to customers. Single instance, multi-tenant, service oriented architectures allow the continual, fine grained exploitation of efficiencies required to make it happen. True SaaS allows a vendor to optimize the usage of the underlying infrastructure; in non-tech speak, true SaaS is what drives Cost of Revenue (COR) down and gross margins up. This leads to a stable foundation for executing long-term strategies. You don’t have to worry about COR going through the roof, or selling a product that is going to buckle under either load or functional weight, even at hundreds of thousands of users. You have a stable foundation for executing growth strategies for your company.

So, what is not “true SaaS”? (Please note I said true SaaS; many of these architectures allow for delivery via the SaaS paradigm, just not optimally) For starters, true SaaS is not a standard web application or standard application with a recurring pricing model and subscription management slapped in front of it. There is no notion of multi-tenant in this scenario and any claims to such a feat would be akin to claiming that OS/2 & Windows NT could be made multi-user by slapping a user login at boot. Anyone who has built an OS understands that there are deep, fundamental differences between a multi-user operating system and a multi-single user operating system (like Windows NT, where based on login you are “multiplexed” to your data and that’s about it). Next, SaaS is not inherently more beneficial or cost effective than perpetual license models. It simply opens the door to be more cost effective. Developers and vendors really need to understand this because done wrong, SaaS would turn out just as bad as its perpetual counterparts. Let’s not forget that a company looking to purchase a perpetual license need not pay up front, they can finance and amortize the cost over time. In order for SaaS to be more cost effective, SaaS vendors need to concentrate on exploiting the efficiencies and economies potential of the delivery model and passing the savings on to their end users. To do this correctly and to maximum capacity, a multi-user, single instance, SOA system is key. Efficiency is not a property that is easily attained through a traditionally architected web application, and even less so with a traditional client side application. If you look at Gianpaolo’s Simple Maturity Model, most standard web apps fall under level 0 or level 1. While they “work”, so does playing golf with a pack of Twizzler’s (only that it’ll take you the better part of a year on a par 5).

Trying to manage thousands of customers all through a multiplexed, multi-instance environment will prove to be more and more difficult as time goes on. By nature, a superb SaaS architecture is intended to provide you a foundational basis for your business model. Keep this in mind if you’re considering going down the SaaS route, particularly if you are looking for a SaaS enablement platform (make sure they help you achieve SaaS purity).

read more

Related Posts

Tags

Share This