Google Apps Premier Edition

Feb 22, 2007 by Matt Ammerman

This is just a mini-post to aggregate the plethora of commentary surrounding the announcement of Google Apps Premier Edition.  Phrases like “in direct competition with Microsoft Office” abound, but overall it’s apparent that there are still a tremendous amount of questions surrounding the maturity level of the application suite.

Here’s a bit of what’s being said:

• Don Dodge - Microsoft Emerging Business Team
• TechCrunch
• CNET
• Donna Bogatin – ZDNet
• Information Week

The question of competitive landscape comes up quite a bit in these discussions.  Is Google Apps Premier Edition as a whole product actually in direct competition with MS Office? Don Dodge offers some very good examples of why it is not. It seems that Google Apps’ aggregate features fall in between the intentional sparcity of the 37signals collaboration suite, and the common robustness and sheer power of MS Office.  As Google starts to elbow its way into the market MS is in a position to adapt and continue to innovate, it’s companies like Zoho and 37signals that should really be concerned (not to mention the price comparisons – $50 per user/per year for Google Apps Premier vs. $149 per user/ per month for 37signals’ BaseCamp).

What are your thoughts?  Where does Google’s play sit in the landscape of enterprise communication and collaboration?

read more

Mini-Update on the Channels Post

Feb 16, 2007 by Sinclair Schuller

If you haven’t read it, I wrote a post the other day regarding traditional sales channels and SaaS end users, highlighting the potential need to reach these end users with creative partnerships. I used the NetSuite/CompUSA partnership as an example. I bumped into a post over on Phil Wainewrights blog this morning about NetSuite’s recent parternship with eBay. Personally, I like the proposition and really is a unique way to approach the reach problem through partnerships. This particular instance is a technical and business partnership. Phil discusses eBay’s business user base as a potential customer route for NetSuite, and I definitely agree. Furthermore, I think it exposes people to B2B on-demand software, which is always a plus.

read more

Do Traditional Channels Matter in a SaaS World?

Feb 15, 2007 by Sinclair Schuller

From the vendor’s perspective, SaaS is more than just a distribution model; it’s a new way of doing business. Many of you have heard it before; no more large license-fee deals, issues with compensating your sales team, planning around incrementally growing yet recurring revenue, etc. The single most important question, however, is “How do I sell?” SaaS poses an interesting scenario: as a provider, you now have extended your distribution power and reduced your per-unit cost basis low enough that your application is a no-brainer deal for the small-to-medium sized business (SMB), but how do you reach these SMBs? Obviously, the mid to enterprise market has warmed up to SaaS so that’s a great market to tackle, but there are established IT inroads into members of this market. There are many, many SMBs out there each without a CIO or CTO or any other obvious “goto” inroad. Getting the idea of on-tap software functionality out to this market is a very big challenge. In my opinion, SaaS providers that attempt to leverage traditional distribution and sales channels with SMBs in mind probably won’t find it to be too successful. I’m betting that SaaS providers targeting this space will have to use a lot of creativity to achieve a broad and deep reach across the SMB space.

A good starting point would be to answer the question “Where do SMBs do business?” or “Who do SMBs work with that I can utilize as channels?” An example (albeit experimental in feel and nature) was NetSuite’s deal with CompUSA last year; CompUSA has many SMBs as clients, and could potentially act as a point of sale for NetSuite subscriptions as well as provide NetSuite training to customers. Although this might not be the “killer channel”, it’s a decent example of creativity. We’ll see more of this unfold as vendors try and tackle the space. Any thoughts? If you’re a SaaS provider, have you had any success with some sort of non-traditional channel or partnership pairing?

read more

Is Salesforce.com’s Apex a Platform?

Feb 6, 2007 by Matt Ammerman

It’s been a few months now since Salesforce.com introduced Apex to the world, and we’ve all had ample time to digest the concept, analyze it, debate about it, and just generally figure out our own positions on the proposition.  One thing’s for sure, the announcement of Apex brought the total level of industry ‘saas platform’ buzz somewhere into the realm of, oh, stratospheric.  Salesforce.com, of course, should be commended for this.  But now here we are roughly five months later and the landscape for SaaS in the enterprise software market, regardless of Apex, has grown and changed drastically.  Platform players have emerged, some having SaaS platform offerings in development long before the Apex announcement.  Some pure play SaaS application vendors are backpedaling to attack the platform need.  Some platforms formed through partnerships between partial solution providers.  Although we may use the term ‘platform’ for them all, there are decidedly different approaches to the concept, even this early in the game.  So now that the field has widened we can frame Apex against a broader notion of SaaS platforms, their requirements, and the different approaches being taken to provide SaaS enablement.  It is time to re-examine our initial response to Apex.  I wonder, is Apex really what SaaS vendors need?  In fact, I dare ask: is it really a platform?

As has been the case before, Salesforce’s own marketing messages have kindled these kinds of questions in my mind.  The kind of questions that make me furrow my brow and think “Just what do they really mean by that?”  Take, for example:

1. George Hu, Salesforce.com’s chief marketing officer said during a keynote speech to an audience of developers: “Go out and create the next Salesforce.com” 
2. A press release dated Jan 16 of this year reads “With Apex, Anyone Can Create the Next Salesforce.com ”
3. And you know I’m not going to leave this one out: Speaking to an audience of customers, CEO Marc Benioff said “We want you to be the next Salesforce.com” 

Sure it seems like a kind-hearted message with success written all over it, and it is undeniably unified in its presentation.  But now couple that mantra with the technological implementation that is Apex and here is where the meat of my questions arise.  According to their own Apex landing page, Salesforce.com wants you to create the next Salesforce.com using the ”same tools that salesforce.com’s own development team uses to build” [salesforce.com].  Besides being a lot of Salesforce.com’s in one sentence, this seems like a cleverly veiled way of saying “we’ll let you build the next Salesforce.com, but no better.  And we’ll keep you from doing this by giving you only the tools that we give our own application developers (or gave them months ago)… who you may ultimately be competing with.”  Remember, a good deal of Salesforce.com’s AppExchange apps are indeed of their own making.  See, this way Salesforce.com’s own developers define a ceiling… a guarded gate through which the ISVs they are ‘enabling’ cannot pass through.  You see, you can’t really create the next Salesforce.com; you may be able to create what Salesforce.com is today.  Tomorrow Salesforce.com will have progressed, and then you can try to be that.  Sound fun?  Sound endless?  By bringing in developers through Apex, Salesforce.com is swallowing competition in an enterprise application market that it is certainly not abandoning.  Is Apex simply a vehicle for making sure that Salesforce.com stays ahead of the game?  After all, if you outgrow or otherwise find little need for the tools provided to you by Apex, you pretty much have to dismantle your application and start over on a different technology stack - putting you far far behind.  Sounds kind of Borg-ish to me.  Come to think of it… didn’t we talk about the risks of this thing called lock-in before?  In the case of Apex we might be talking about lock-in through assimilation!  Heck, you even have to learn the Apex language.  I rest my case.

In all fairness, an answer to this question may require a solid grasp of the definition of ‘platform’, and in the context of the SaaS world this definition is constantly being tugged at and remolded.  However, here’s something to start with:  I propose that a true SaaS platform, one that will in fact revolutionize the industry from the perspective of the ISV and end user alike, is not a body of technological implementation that binds and assimilates and attempts to lead by example (Ahem. “We want you to be us.”), but one that can better be likened to the traditional concept of the platform that is used for elevation – not of the platform itself, but of those that stand upon it.  Yes, I am saying that a SaaS platform must get out of the way of the applications, and likewise the ISV business models, it enables.  ISVs will find true enablement through a platform that serves only one purpose, and does it well – to make the development and delivery of robust enterprise SaaS applications as easy as writing software and delivering it on premise.  To elevate, or enable, without demanding explicit recognition from the application or those that use it meets the true definition of a platform. A platform is a very humble, simple, and oft overlooked thing - yet a well-engineered platform silently keeps entities aloft that are many times its size.

And so I turn it over to you:

Is Apex really a platform?

 

*** UPDATE 2/7/07 9:56am ***

Marketing Consultant Joe Bentzel wrote a similarly-themed article a couple of weeks ago.  This is terrific further reading: Salesforce.com APEX: Platform or ‘Platformula’?

 

 

read more

SaaS Provider Buckle Risk

Jan 30, 2007 by Sinclair Schuller

Alarmist titles are great, aren’t they? In all seriousness, I don’t intend to take an alarmist position in this post. However, I do want to highlight something that we discuss at Apprenda as the “buckle risk” that SaaS providers must deal with.

Rapid growth, when used as a blanket term, tends to be associated with success due to the positive connotation of growth and the generally accepted positive implications of something growing from smaller to bigger. For example, rapid revenue growth is good for a company, correct? Not always. A classic problem is burning through cash to match the operational needs of rapid revenue growth, and not giving time for the bottom line to “sink in.” Have any of you ever read the story of the sports apparel company 180s? If you’re in any type of business, you should read this story if you haven’t. Outside of the business world, rapid growth can have negative effects as well: dogs that grow too rapidly as puppies frequently develop hip dysplasia, or cities and towns (or any populace structure) that grow too fast frequently experience difficulty maintaining quality of life for residents. Generally, all of these had one thing in common: the unchecked growth severely taxed available or existing resources leading to unexpected or unintended consequences. So what does this have to do with SaaS providers and what in the world is “buckle risk”?

“Buckle risk” is best understood as the risk a SaaS provider takes on when planning for growth of their subscriber base on an unproven/untested technical architecture and infrastructure. Growing your subscriber base creates a “double edged sword” scenario, particularly if you’re building and deploying an enterprise SaaS application. You need a large and growing subscriber base to attract larger customers, but if your base grows too big too quickly, you could end up with service hiccups that alienate (and shrink) your existing base. Worse yet, your hiccup turns into an all out “buckling” of your infrastructure that takes a couple of days to get working again. Enterprise customers don’t like this very much, and are much less forgiving than consumers. This forces you to ask many questions. Did you make the right data partitioning choices? The right architectural choices when factoring in scalability? How about your hardware infrastructure? If it’s in house, did you set it up well? If it’s outsourced, what sort of SLA do you have from your provider and can they handle your load? How large of a subscriber base can you support before you “buckle” and have to spend time and money adjusting: 5 thousand users, 10 thousand users, 20 thousand users? In the best case scenario, these problems affect your economies of scale and reduce your margins (which is not too good of a best case scenario, since SaaS is very much a margins game for the provider).

You’ll here responses on this topic of “We’d be happy to have that problem” or “We’ll figure it out when we get there.” Traditionally, this approach has worked; we’re all guilty of sacrificing load capability early on in a project for on-premise software because we can release a patch or tell the customer to cluster some servers together when it becomes a problem. With a SaaS architecture, releasing a patch of a certain magnitude can be far too expensive and risky, at least much more so than distributing a patch one-by-one to on-premise customers. Relying strictly on hardware scale-out/up can be pricey in the short term. Planning around this problem early, however, is the best solution. Look for ways to build or deploy SaaS applications that reduce “buckle risk.” If you’re a SaaS provider, is this something you’ve dealt with or are concerned about?

read more