SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for the ‘enterprise software’ Category

Let’s Try Another Verse of Your SaaS Company Does Not Need a Sales Force

Posted by Bob Warfield on May 23, 2014

MorpheusNoSalesForceIt’s time for another installment of what some of the Enterprise Irregulars have called the Jason and Bob show.  Jason and I have disagreed on a fair number of issues over time, though we have also agreed on a lot.  Jason’s had a great run and is now in the rarefied atmosphere of VC’s.  All of his material is thought provoking and well worth a read.

Today, we’re going to talk about Outside Sales or indeed the question of whether SaaS companies must have a sales force at all, inside, outside, or otherwise.

Jason’s post today is “Inbound or Outbound Sales? The Answer is Yes.”  In it, he argues that

There’s a meme, a CommonThink, among certain segments that Outbound Sales is Bad, or at least, a Little Unseemly.  And maybe a lot bit Old School.

That we’re in a new world of sales, a new consultative world, where leads come in, prospects can try and learn before they even talk to a human, and then, a sales rep thoughtfully answers questions, models business process change, and helps them decide how and why, and if, to buy.

And that’s true.  We are in that world.  Inside sales is terrific.  Warm leads are great.  Live trials of easy-to-use-and-deploy web services really have changed the game.

And yet …

The reality is, by revenue, this isn’t the way the majority of the world buys.

My role here today is to cast a dissenting vote, and to explain why.  In fact, this one’s been argued between us before so I’ll just refer you gentle readers to my original response to get the ball rolling:

Does your SaaS company have to have a sales force?

In that article I make the case that, no, your SaaS company doesn’t automatically need Outside Sales. It’s a function of who you need to sell to and that’s a function of what your solution costs. The more money involved in an individual sale, the more likely you need Outside Sales.  This isn’t really news or something I made up, by the way.  I learned it at the knee of one Geoffrey Moore, he of the Chasms and Gorillas and such.  I find it makes a lot of sense to think about how you need to sell based on the size of the transaction involved.  In hindsight, it’s obvious that a very expensive purchase carries a lot of risk and that a large organization will need to involve many people and ultimately a highly placed decision maker to get it done.

Jason does tip his hat to this notion with some remarks about selling to SVP’s, but I believe it’s something that startups need to think really carefully about very early on.  Horses for courses. What’s the right way to sell for my specific product and opportunity?  You need to make a conscious choice during the very early stages of the startup about what your strategy will be in this respect, because it’s going to have a profound impact on what sort of company you’re building, what kinds of skills you will need, and even the capital needs of your venture.

Jason mentions the “meme” that Outbound Sales is Bad.  Surely that’s damning with faint praise, but there are sound reasons why that meme is out there.  He says, “by revenue, this isn’t the way the majority of the world buys,” referring to purchasing without the need for Outside Sales.  Au contrare, Jason.  I don’t believe it and I have never seen any data to support it.  In fact, you don’t have to look far to see that the biggest revenue is associated with offerings that don’t require either inside or outside sales. Think Apple, Walmart, et al. Their selling is totally self-service and marketing-driven. Not software? How about Google or Facebook? Oh, not business enough? What about Github, Amazon Web Services, or many other ventures that are hugely successful.  While we’re at it, let’s look to where the majority of the profit, not the revenue goes and the differences are even more stark in favor of finding models that don’t require Sales.

What if that’s the real opportunity–start something that works and doesn’t require Outside Sales.  Or if you prefer, consider the potential for disruption that going into a market with a product that can work without Outside Sales offers. That’s exactly what PC’s did to the Minicomputer vendors. The Rolex-clad, scratch golfing, Armani suited crowd with good haircuts laughed at the little computer stores and the pathetic IBM PC.  Ken Olson himself laughed at them all the way to the point where DEC disappeared and was never heard from again and in a very short span of time.  Hitting an Outside Sales-driven industry with a solution that requires no sales creates the Mother of all channel conflicts for the poor sales-driven company.  It is just as toxic to companies with Sales Forces as Subscription models are to Perpetual License models.

The other reason the meme is strong is capital requirements.  Outside Sales-driven opportunities are going to require more capital to finance their longer sales cycle.  It’s unavoidable when you have to wind your way through the organizational complexity that’s there to stop a company from foolishly spending its money without proper checks and balances on your expensive solution.  SaaS itself is already capital inefficient because it pulls expenses forward and pushes profit out over time relative to getting it all up front in the Perpetual License model.  We live with it to get to the pot of gold at the end of the rainbow, but what if we could at least mitigate it by selling a product cheap and easy enough that it didn’t need Outside Sales or even Inside Sales?

That’s how the companies I’ve mentioned got to be so big so quickly.  That’s why this so-called meme is a real business strategy that’s disruptive and must be considered by any startup.

Figuring out how to leverage strategies like this in new markets where you can be supremely disruptive to the incumbents is what successful startups are all about.  Don’t be a slave to tradition.  You’re not here to build another SAP.  You’re here to build the next generation by disrupting SAP and Oracle.  SaaS is probably not enough to do that, though some argue otherwise.   I think many of those are confusing disruption with room at the bottom (great link from Jason, BTW).  The thing is, everyone’s doing SaaS now, so what’s different about your story?

 

Posted in bootstrapping, business, enterprise software, Marketing, strategy | Leave a Comment »

Big Data is a Small Market Compared to Suburban Data

Posted by Bob Warfield on February 2, 2013

BurbsBig Data is all the rage, and seem to be one of the prime targets for new entrepreneurial ventures since VC-dom started to move from Consumer Internet to Enterprise recently.  Yet, I remain skeptical about Big Data for a variety of reasons.  As I’ve noted before, it seems to be a premature optimization for most companies.  That post angered the Digerati who are quite taken with their NoSQL shiny objects, but there have been others since who reach much the same conclusion.  The truth is, Moore’s Law scales faster than most organizations can scale their creation of data.  Yes, there are some few out of millions of companies that are large enough to really need Big Data and yes, it is so fashionable right now that many who don’t need it will be talking about it and using it just so they can be part of the new new thing.  But they’re risking the problems many have had when they adopt the new new thing for fashion rather than because it solves real problems they have.

This post is not really about Big Data, other than to point out that I think it is a relatively small market in the end.  It’ll go the way of Object Oriented Databases by launching some helpful new ideas, the best of which will be adopted by the entrenched vendors before the OODB companies can reach interesting scales.  So it will be with Hadoop, NoSQL, and the rest of the Big Data Mafia.  For those who want to get a head start on the next wave, and on a wave that is destined to be much more horizontal, much larger, and of much greater appeal, I offer the notion of Suburban Data.

While I shudder at the thought of any new buzzwords, Suburban Data is what I’ve come up with when thinking about the problem of massively parallel architectures that are so loosely coupled (or perhaps not coupled at all) that they don’t need to deal with many of the hard consistency problems of Big Data.  They don’t care because what they are is architectures optimized to create a Suburb of very loosely coordinated and relatively small collections of data.  Think of Big Data’s problems as being those of the inner city where there is tremendous congestion, real estate is extremely expensive, and it makes sense to build up, not out.  Think Manhattan.  It’s very sexy and a wonderful place to visit, but a lot of us wouldn’t want to live there.  Suburban Data, on the other hand, is all about the suburbs.  Instead of building giant apartment buildings where everyone is in very close proximity, Suburban Data is about maximizing the potential of detached single family dwellings.  It’s decentralized and there is no need for excruciatingly difficult parallel algorithms to ration scarce services and enforce consistency across terabytes.

Let’s consider a few Real World application examples.

WordPress.com is a great place to start.  It consists of many instances of WordPress blogs.  Anyone who likes can get one for free.  I have several, including this Smoothspan Blog.  Most of the functionality offered by wp.com does not have to coordinate between individual blogs.  Rather, it’s all about administering a very large number of blogs that individually have very modest requirements on the power of the underlying architecture.  Yes, there are some features that are coordinated, but the vast majority of functionality, and the functionality I tend to use, is not.  If you can see the WordPress.com example, web site hosting services are another obvious example.  They just want to give out instances as cheaply as possible.  Every blog or website is its own single family home.

There are a lot of examples along these lines in the Internet world.  Any offering where the need to communicate and coordinate between different tenants is minimized is a good candidate.  Another huge area of opportunity for Suburban Data are SaaS companies of all kinds.  Unless a SaaS company is exclusively focused on extremely large customers, the requirements of an average SaaS instance in the multi-tenant architecture are modest.  What customers want is precisely the detached single family dwelling, at least that’s what they want from a User Experience perspective.  Given that SaaS is the new way of the world, and even a solo bootstrapper can create a successful SaaS offering, this is truly a huge market.  The potential here is staggering, because this is the commodity market.

Look at the major paradigm shifts that have come before and most have amounted to a very similar (metaphorically) transition.  We went from huge centralized mainframes to mini-computers.  We went from mini-computers to PC’s.  Many argue we’re in the midst of going from PC’s to Mobile.  Suburban Data is all about how to create architectures that are optimal for creating Suburbs of users.

What might such architectures look like?

First, I think it is safe to say that while existing technologies such as virtualization and the increasing number of server hardware architectures being optimized for data center use (Facebook and Google have proprietary hardware architectures for their servers) are a start, there is a lot more that’s possible and the job has hardly begun.  To be the next Oracle in the space needs a completely clean sheet design from top to bottom.  I’m not going to map the architecture out in great detail because its early days and frankly I don’t know all the details.  But, let’s Blue Sky a bit.

Imagine an architecture that puts at least 128 x86 compatible (we need a commodity instruction set for our Suburbs) cores along with all the RAM and Flash Disc storage they need onto the equivalent of a memory stick for today’s desktop PC’s.  Because power and cooling are two of the biggest challenges in modern data centers, the Core Stick will use the most miserly architectures possible–we want a lot of cores with reasonable but no extravagant clock speeds.  Think per-core power consumption suitable for Mobile Devices more than desktops.  For software, let’s imagine these cores run an OS Kernel that’s built around virtualization and the needs of Suburban Data from the ground up.  Further, there is a service layer running on top of the OS that’s also optimized for the Suburban Data world but has the basics all ready to go:  Apache Web Server and MySQL.  In short, you have 128 Amazon EC2 instances potent enough to run 90% of the web sites on the Internet.  Now let’s create backplanes that fit a typical 19″ rack set up with all the right UPS and DC power capabilities the big data centers already know how to do well.  The name of the game will be Core Density.  We get 128 on a memory stick, and let’s say 128 sticks in a 1U rack mount, so we can support 16K web instances in one of those rack mounts.

There will many valuable problems to solve with such architectures, and hence many opportunities for new players to make money.  Consider what has to be done to reinvent hierarchical storage manage for such architectures.  We’ve got a Flash local disc with each core, but it is probably relatively small.  Hence we need access to storage on a hierarchical basis so we can consume as much as we want and it seamlessly works.  Or, consider communicating with and managing the cores.  The only connections to the Core Stick should be very high speed Ethernet and power.  Perhaps we’ll want some out of band control signals for security’s sake as well.  Want to talk to one of these little gems, just fire up the browser and connect to its IP address.  BTW, we probably want full software net fabric capabilities on the stick.

It’ll take quite a while to design, build, and mature such architectures.  That’s fine, it’ll give us several more Moore cycles in which to cement the inevitability of these architectures.

You see what I mean when I say this is a whole new ballgame and a much bigger market than Big Data?  It goes much deeper and will wind up being the fabric of the Internet and Cloud of tomorrow.

Posted in business, cloud, data center, enterprise software, multicore, platforms, saas, service | 2 Comments »

Dim Dim: The Risk of Being a Salesforce Customer

Posted by Bob Warfield on January 7, 2011

unhappy customersMy title is a bit of a play on ReadWriteWeb’s title about the Risk of a Free Service, but I raise the issue in all seriousness because I think we should be looking not at the seller (hey, at this price, this was not exactly a sale from strength) but at the buyer.  Dennis Howlett, in writing about the transaction, is doing a little bit of looking at the buyer, but I want to go further.

The way a company handles the customers of an acquisition is an indication of how they may someday feel about their own customers.  When you buy the company, you bought the customers too.  Sure, it’s all fine and well to argue that you bought the technology and not the customers and it’s not your fault that the customers don’t fit in with your plans and so won’t be treated well.  But when you hear that rationale, ask yourself,  “What happens if I’m a customer of such an organization and suddenly I don’t fit in with their plans either?”  There’s not really a difference, particularly not if you are a just one customer among many of a large company.  If Salesforce was going to do what I’d want it to do if I were a Dim Dim customer, they’d be grandfathering me in and extending me full benefits of being a Salesforce customer.  They’d be welcoming me to the family instead of disinheriting me.  I’d be 10x more likely to want to buy something from them if they did, and I’d be 10x more likely to sing their praises and those of Dim Dim going forward regardless.   Unless I miss my guess, Salesforce is going to be doing a lot more acquisitions, so take note of the tone they’re setting.

There are really two kinds of successful businesses out there:  There is the business that would do anything for its customers, and then there is the business run by the numbers that is without soul or pity for their customers.  I won’t be disingenuous by claiming the soulless kind doesn’t work, neither will I argue that one is better.  We have big and successful examples of companies that do as they please with their customers–Oracle and Microsoft have both been accused of such more than once so it should be no secret.  We also have examples of companies who have put their customers above all else–I like companies like Zappo’s and Nordstrom or maybe Amazon and Apple (in a curious way, they do care, they just think they know best).  Some of Hurd’s problem at HP may have been putting a numbers guy in charge of a culture driven more by ideals.  We will see whether Apotheker is a better fit.

When the pure numbers companies make an acquisition, it’s pretty clear how things will work.  Fellow Enterprise Irregular Naomi Bloom has a wonderful post out about fairy tales in the land of HR software that describes some of the goings on you should expect:

- We (the acquirer) will continue to support all product lines fully:  Of course we really won’t, we can’t afford to, but we don’t want to tell you that too soon.

We (the acquirer) are delighted with our new colleagues and expect to retain all of them:  Even if we do retain them, and we won’t, they will be disempowered and will be bent to our culture and management.  Expect many to leave as soon as the handcuffs are off.

- Our customers can expect to see only improvements in their support, product roadmaps, and overall happiness as a result of this event:  Well, maybe, if it’s a technology acquisition.  If it is a market share acquisition, we are reducing the competitiveness of the market so that we may extract more profit while delivering less.

To those Fairy Tales, meaning if you hear them you should see them as red flags, I will add that if you see one of your vendors acquire a company and fail to welcome its customers with open arms to the family the way you would have liked to have been treated, that’s a red flag too.

There’s another thread I want to pick up on before I leave this one.  When we look at the two types of companies, ironically, making the customer King often leads to excellent profitability and shareholder value, but focusing on short-term numbers tweaking does not.  One of the disappointing things for me is how often products that were once great and companies can fade into obscurity.  I asked one of my favorite mentors one time what he was proudest of about the company where we had worked together.  His answer was very telling–his biggest accomplishment, he felt, was in creating a great culture.  This was a company that cared foremost for customers, and that culture resulted in an employee base that was very resilient to adverse conditions and very talented.  Later, the company got numbers focused and it has since lost that culture and most of those people.  Culture is the currency for a company that cares about its customers, but what is the currency that makes a big company out of one that cares for numbers?  Looking around for that answer I can only conclude that it is monopoly, customer lock-in, and the inertia that comes to all things big.  These are the only reasons for customers to put up with a company that cares more about its profits than about the customer.

Last point:  I read with interest Chris Sellend’s (lots of us Enterprise Irregulars with something to say!) prediction of a coming Social-Media-in-Marketing backlash.  Riffing on @pgillin, he calls for a Social Marketing Hangover.  I think folks calling for this backlash are right, but perhaps not in the way some of them are thinking.  Think about the two kinds of companies then think about what Social is.  The answer is obvious (to me at least):  companies that have a culture that cares about customers can be wildly successful with Social while customers with cultures that only care about the numbers are doomed to fail.  There is some question in my mind about whether they should even try, though there is a sentiment that feels opening themselves up to customers will let the customers rehabilitate them. 

The real tragedy is it will never occur to the number crunchers what is wrong and the pundits will watch the train wrecks and simply conclude Social was more hype than reality.  The customer-centric crowd won’t notice anything big either except that they can suddenly do what they do best a whole lot easier.

Posted in business, customer service, enterprise software, saas, service, venture | 2 Comments »

CIO’s: How Will You Avoid Social Silos?

Posted by Bob Warfield on December 21, 2010

I’m a firm believer that maximizing the ROI of your Social efforts in the Enterprise requires deeply integrating your Social Platforms with your Enterprise Software Platforms. 

The major Enterprise Software players are well aware of the importance of Social Software as well as the advantages of deep integration for ROI.  This is why we have SuccessFactors acquiring Cubetree, Salesforce investing heavily in Chatter, and so on.  Indeed, a lot of the uniqueness of Salesforce’s Chatter is it’s integation with business process.

There’s just one problem: if every Enterprise Vendor is going to acquire and build a social platform, how are we going to tie them all together and avoid Social Silos?

It gets worse.  To really maximize the value of your Social Platforms, you need to involve not just employees, but also your customers and partners.

Working through a set of requirements questions CIO’s should be considering for their Social Platforms is the topic for this week’s Smoothspan Sponsored InfoBoom post.  Check it out!

Posted in business, enterprise software, Web 2.0 | Leave a Comment »

Check out IBM’s InfoBoom

Posted by Bob Warfield on December 7, 2010

By way of introduction, I just made my first post as a Sponsored SubjectExpert on IBM”s InfoBoom community, and it was a doozy.  Think of it as an appropriate next chapter to follow my Enterprise 2.0 is Dead post, because it talks about a new (actually getting to be pretty widespread) concept in Social Business Software that some have taken to calling “Procial.”  It’s the idea of layering in some highly integrated but conventional business process software with social.  Salesforce has layered their entire ecosystem as a productivity layer under Chatter, for example (some would say I have it backwards which is layering which, LOL).

The post can be found on InfoBoom as “Talking Pro-cial With Teambox.”

On InfoBoom itself, it’s a community sponsored by IBM for IT professionals that’s focused on the major megatrends facing IT today:

-  BI

-  Data Security

-  Green IT

-  Governance

-  Social Media for Business

-  Cloud Computing

Given the last two, you can see why they picked Smoothspan to do a little blogging there.  If you’ve never visited a first-class community for business (I hestitate to call it a Facebook for grown ups because that isn’t fair to Facebook), it’s worth checking it out.  Lots of interesting ideas for how to go about it.

Related Articles

Catch Tony Nemelka’s guest post on Esteban Kolsky’s blog.  When I read Tony saying that E2.0 vendors have been skating to where the puck is, but that the goal is now behind them, and he goes on to say customers want E2.0 to “Integrate with how we operate. Don’t interrupt. Become part of the fabric. Follow our lead. We’re in control of things now,” it resonates with what I’m saying here.  Social without full integration to an existing and important business process is missing some very important beef.

Posted in business, enterprise software, Web 2.0 | Leave a Comment »

Heretical Thinking: Enterprise 2.0 is Dead

Posted by Bob Warfield on November 11, 2010

After reading Dennis Howlett’s piece, “Enterprise 2.0 is beyond a crock.  It’s dead,” and Andrew McAfee’s counterpoint, “Social Business is Past Retirement Age,” I found myself in the surprising position of agreeing with Dennis that E2.0 is dead.  I’m not suprised because of any issue with Dennis, I’ve been reading and enjoying his work for years, but rather because I would’ve expected to come out more on the side of E2.0 idealists.  After all, I was very recently involved in a closely related space called Social CRM, and I’m supposed to be a card-carrying “Social Guy.”  Dennis has never made a secret of his skepticism.

Where's The Beef?

Where's The Beef?

Here is my problem:  the Business Social Scene has rolled forward under the banner of the Consumerization of IT and not much else.  That’s a polite way of saying they’ve copied everything they can from Facebook, Twitter, and online BBS systems, without adding much innovation of their own.  They’ve made it possible to visit the water cooler without leaving your desk, but that’s hardly an excuse for big ROI payoff. 

Because of my past, I find myself talking to lots of companies that are interested in Social for Business.  If there is one thing that constantly surprises me, it is the sameness of their approach.  Really the only interesting new thing I’ve heard of was Chatter’s ability to have the Enterprise Software itself participate in the conversation. 

Take recent reviews of Moxie (used to be called nGenera) where two reviewers (Ben Kepes and Klint Finley) remark along these lines:

Moxie is a full-featured social suite including internal and external community sites, wikis, idea management, microblogging and more. Ben Kepes is not particularly impressed by Moxie. He lists the things Moxie told him in a briefing set it apart:

  • Pointers to people (think rich profiles and the like)
  • Rewards for participants (thinks badges and stuff – yawn)
  • Going where the people are (single sign on and enterprise integration)
  • A compelling UI (code for “we look like Facebook”)

I was basically told the same thing in my briefing, and I agree that most of this is all pretty common place – except maybe badges, which aren’t a big deal.

I saw the demo some time ago and had the same reaction.  They’re awfully late to the party to be showing a Me Too product, even if it does have a little nicer fit and finish than many.

The trouble is, almost everyone is late to this party in some sense or another because they’re all so similar.  That means that the consolidation that’s already underway (where companies like Cubetree are bought by companies like SuccessFactors) will continue or accelerate. 

There is also another disturbing tendency, and this is where Howlett’s piece really resonates and Andrew McAfee lets us down as an academic: it’s gotten to be all about faith and marketing.  When it comes to ROI, “Where’s the Beef?”  Discussions of ROI quickly turn circular:  You can’t get the ROI until everyone is participating, but once they are, we’re sure the ROI will be huge.  Dennis’ point is that in the end of the day, it’s all down to the people and their culture.  If you have a company with a culture that’s capable of embracing E2.0, you may get some value from it.  If not, fuggedhaboutit.  And this is where my problems with Andrew McAfee start.  He says the idea of a “Social Business”, is old as the hills, and E2.0 is the new new thing we have to focus on.  In talking about “Social Business” (how people behave) versus E2.0 (Tools), he pens a great passage that if I were he, I couldn’t imagine wanting to be held accountable for:

This distinction matters. It matters because telling business decision makers “There are some important new (social) technologies available now, and they’ll help you address longstanding and vexing challenges you have” is very different than telling them “Business is social, and the more deeply you embrace that fact the better off you’ll be.”

Absent any other information, I would’ve expected McAfee to immediately embrace his second statement and move on.  Wouldn’t you?  After all, it is the more profound and more accurate statement.  The first is more faith marketing from the E2.0 cheerleader’s squad.  Imagine my surprise at his next paragraph:

The former sentence, I’ve found, is pretty effective at getting their attention. The latter one is less so, because I tell you with complete certainty that they’ve heard it many many times before. It’s a message that has been broadcast into the executive suite for fourscore years now. Sometimes it’s been delivered with great skill and clarity, sometimes not. Sometimes it’s been internalized and acted on, sometimes not. But the message has been heard so often that it’s faded into the background. I’ve found that the phrases “business is social” and “people, process, and technology matter” have lost most, if not all, of their power to persuade decision makers.

Hold on Andrew, when did you cash in your academic credentials, pick up a bag, and decide your most important job was selling E2.0 software?  Aren’t you supposed to have weightier matters of the mind such as learning something new and discovering the fundamental truths of our time?  Isn’t the fundamental truth, “Business is social, and the more deeply you embrace that fact the better off you’ll be.”

Here’s the deal: we are nearing the end of the time for Faith-Based Marketing.  That’s an Early Adopter’s game.  We’re staring at the chasm and wondering how to get across.  You can’t cross the chasm with a hope and a prayer.  The folks who live on the other side of the chasm are not Early Adopters.  They don’t worship every new shiny thing.  They are more practical and pragmatic people who insist on an ROI.  Chris Yeh puts the mindset of these later adopters in a blunt but accurate fashion:

If you can’t sell more, buy less, or fire somebody, you’re not getting real ROI.

If there is one thing I learned selling Social Software, it is that the issue is very black and white.  You can’t convince people to be Social unless they already are.  There are no grays, and any company that bets its future on turning grays into blacks or whites is going to have such a high cost of Sales and Marketing they will fail.  There is a crowd that believes it’s all down to demographics.  “We just need enough Gen Y’s in decision-making positions and the world will turn Social overnight.”  There is a crowd that looks at Facebook’s 500 million people and concludes, “It’s inevitable and moreover it is here right now today!”  They are both wrong.  They are both relying on Faith rather than actively doing something new.  Remember that old definition of insanity–doing the same thing and expecting a different result.  Get off of Faith and onto ROI and you can talk shades of gray.  Chris puts the E2.0 mindset on ROI equally as bluntly:

I keep hearing that the benefits of E2.0 initiatives will take a long time to accrue and are difficult to measure, but that it’s still worth adopting because the cost of experimentation is so low.

Not to put too fine a point on it, but this is bullshit.

If we’ve been studying the Social Business for such a long time without a result, that’s a clue.  McAfee will argue that’s precisely why he has quit focusing on it and started focusing on the E2.0 world.  But that world has been here long enough too.  Lotus Notes was an E2.0 tool, for Heaven’s Sake.  A few of the E2.0 companies at the very top are doing great, most are so so, and there is a consolidation underway.  If E2.0 is the Megatrend those with the faith think, there should be so much green field that many more of these companies are hitting the ball out of the park.  We should be tee’d up for 3 or 4 IPO’s imminently, just as soon as the market opens.  I don’t get the sense we are there or even close.  We may very well have a repeat of the old Portal market, where despite many companies being in the space, only one (Plumtree) managed to have an IPO, and a tepid one at that.

As an Engineer and Products Guy, I have to comment on the software, and not just stick to the people angle.  I do believe it is possible to do what Moxie claims to have done, and that is to construct a User Experience so compelling that it drives rapid adoption.  To be clear, I don’t think they have done it, just that it is possible someone could.  The fundamental problem with the UX for these products is they start from the assumption that Generic Social is the Goal.  It ain’t the case.  Solving a real Business Problem and Delivering an ROI is the Goal.  This is the essential point McAfee is missing.  In his article, he argues putting people first is dumb because we’ve tried that and nothing happened, while:

What is novel is the digital toolkit available to help businesses and their leaders become more social, more open, more Theory Y, more Model 2, etc. In the 2.0 Era, these tools experienced a quantum leap forward, not an incremental improvement. Because business is so social, this quantum leap is a big deal.

Andrew, the digital toolkit is not nearly compelling enough as it exists today to turn otherwise recalcitrant cultures upside down and thereby prove your thesis.  Cultures that are already very sophisticated in their Social tendencies without the tools can benefit.  Others will not change, and if they would, there would be no end of case studies showing it.  The truth is that recalcitrant culture is corrosive to E2.0.  It kills it dead as Howlett suggests through passive aggression and politics, the way people have always killed things they were afraid of.  Why should a little bit of software upset the very structure on which people build their livelihoods, their reputations, and their power bases?  Andrew, go back and study all those writings about a Social Business that you’ve so eloquently quoted from, because those forces I mention are more than powerful enough to derail E2.0.So are we doomed?  Not at all.  As I mentioned, it is possible to create a UX that is an agent of change.  The trick is to design from the standpoint of not having to change the culture before it can be successful.  That is something that no E2.0 offering to date has yet done, though we have been trying since Ray Ozzie brought us Notes a very long time ago.  How would this new UX operate?  I have some ideas, but let me start with an example of a market where something similar worked with a vengeance. 

Long ago, but still in my recorded memory, there were no such things as spreadsheets.  We had accounting and accounting software, which produced reports.  We had various attempts at using computers large and small to do analysis, mostly by programming.  Very little analysis was actually getting done because despite the availability of simple languages like BASIC, and despite the cult following PC’s were gaining, you had to learn to be a programmer to do it, and that was too hard.  Then along came the spreadsheet.  What an interesting confluence of properies it had:

1. Spreadsheets have tricked more people into becoming progammers than anything else in history.

2. They did this largely by not forcing people to learn to be programmers.

3. Instead, they became an electronic embodiment of what was already being done.  A “spreadsheet” for those that don’t remember what it used to mean, was a particular kind of paper form that accountants would lay out in order to organize their numbers for computation.  They used to call them “electronic spreadsheets”, in fact.  I remember to this day driving over to an accountant’s home to see one for the first time so I could understand what it was people were so excited about.  And there it was, a piece of paper come to life and calculating live numbers as I changed the cells.

The spreadsheet is a metaphor for where E2.0 has to go if it is to regenerate itself, make a huge difference, and Cross the Chasm.  The UX has to start from how people are working today, not how you’d like them to work after they have accepted your E2.0 tool.  Proponents will say, “We’ve already done that!”  It’s true, but they’ve picked the wrong things to emulate and automate.  Wikis are automated the means to publish books or perhaps to keep community filing cabinets.  They’re great.  But who will argue that books or filing cabinets have a radical ROI?  Likewise with automating the water cooler.  If you look at it in that light, have you really solved the water cooler problem so much better that it has a huge ROI?  Was the water cooler ever capable of delivering a huge ROI?  Probably not.

I will leave this post on that note because there are so many business processes that have the huge potential for ROI that to drill down on any particular one would do the others a disservice.  E2.0 vendors, heed the spreadsheet.  Quit trying to automate the water cooler, quit trying to change the culture, and figure out something genuinely new to do besides copying Facebook!

Posted in enterprise software, Marketing, strategy, user interface, Web 2.0 | 11 Comments »

Dell Buys Boomi: Right Inline With My Cloud Strategy

Posted by Bob Warfield on November 2, 2010

Just read that Dell is buying Cloud data integration company Boomi.  That’s right in line with the focus on data strategy I’ve recommended for Cloud vendors.  I’m not sure how many more companies in this space are available to be picked up.  IBM picked up Cast Iron Systems, which was another great catch.

Just a refresher on why these companies are so pivotal, because it amounts to two key observations:

First, Clouds have latency, which creates a network effect.  It’s easier for apps in the same Cloud to talk to each other than it is to go across Clouds.  Hence Clouds are going to accrete applications based on which ones need to talk to each other.

Second, in the SaaS world, integration is a tremendous competitive and transaction friction issue.  No Enterprise application is an island, they all need to talk to some other application.  If that integration has to be done without the leveraging benefits of a supporting technology, if it has to be done strictly as a service, that adds a lot of friction to the transaction.  That friction can slow down sales momentum.  In addition, from a competitive standpoint, SaaS apps are often bought by the Business with the idea that they will cause minimal support overhead for IT.  Whether IT buys into that or not, the availability of suitable integration technology is going to determine how happy everyone is.  If IT has to constantly dive in and bandaid the integration, nobody is happy.  If IT can get comfortable at the outset that the integration solution will be high quality, everyone will be a lot happier.

These data integration acquisitions are very strategic to the Cloud space.  Good on Dell for going after Boomi.

Posted in business, cloud, enterprise software, platforms, saas, strategy | 1 Comment »

Single Tenant, Multitenant, Private and Public Clouds: Oh My!

Posted by Bob Warfield on August 27, 2010

My head is starting to hurt with all the back and forth among my Enterprise Irregulars buddies about the relationships between the complex concepts of Multitenancy, Private, and Public Clouds.  A set of disjoint conversations and posts came together like the whirlpool in the bottom of a tub when it drains.  I was busy with other things and didn’t get a chance to really respond until I was well and truly sucked into the vortex.  Apologies for the long post, but so many wonderful cans of worms finally got opened that I just have to try to deal with a few of them.  That’s why I love these Irregulars!

To start, let me rehash some of the many memes that had me preparing to respond:

Josh Greenbaum’s assertion that Multitenancy is a Vendor, not a Customer Issue.  This post includes some choice observations like:

While the benefits that multi-tenancy can provide are manifold for the vendor, these rationales don’t hold water on the user side.

That is not to say that customers can’t benefit from multi-tenancy. They can, but the effects of multi-tenancy for users are side-benefits, subordinate to the vendors’ benefits. This means, IMO, that a customer that looks at multi-tenancy as a key criteria for acquiring a new piece of functionality is basing their decision on factors that are not directly relevant to their TCO, all other factors being equal.

and:

Multi-tenancy promises to age gracelessly as this market matures.

Not to mention:

Most of the main benefits of multi-tenancy – every customer is on the same version and is updated simultaneously, in particular – are vendor benefits that don’t intrinsically benefit customers directly.

The implication being that someone somewhere will provide an alternate technology very soon that works just as good or better than multitenancy.  Wow.  Lots to disagree with there.  My ears are still ringing from the sound of the steel gauntlet that was thrown down.

-  Phil Wainewright took a little of the edge of my ire with his response post to Josh, “Single Tenancy, the DEC Rainbow of SaaS.”  Basically, Phil says that any would-be SaaS vendor trying to create an offering without multitenancy is doomed as the DEC Rainbow was.  They have some that sort of walks and quacks like a SaaS offering but that can’t really deliver the goods.

-  Well of course Josh had to respond with a post that ends with:

I think the pricing and services pressure of the multi-tenant vendors will force single-tenant vendors to make their offerings as compatible as possible. But as long as they are compatible with the promises of multi-tenancy, they don’t need to actually be multi-tenant to compete in the market.

That’s kind of like saying, “I’m right so long as nothing happens to make me wrong.”  Where are the facts that show this counter case is anything beyond imagination?  Who has built a SaaS application that does not include multitenancy but that delivers all the benefits?

Meanwhile back at the ranch (we EI’s need a colorful name for our private community where the feathers really start to fly as we chew the bones of some good debates), still more fascinating points and counterpoints were being made as the topic of public vs private clouds came up (paraphrasing):

-  Is there any value in private clouds?

-  Do public clouds result in less lock-in than private clouds?

-  Are private clouds and single tenant (sic) SaaS apps just Old School vendors attempts to hang on while the New Era dawns?  Attempts that will ultimately prove terribly flawed?

-  Can the economics of private clouds ever compete with public?

-  BTW, eBay now uses Amazon for “burst” loads and purchases servers for a few hours at a time on their peak periods.  Cool!

-  Companies like Eucalyptus and Nimbula are trying to make Private Clouds that are completely fungible with Public Clouds.  If you  in private cloud frameworks like these means you have
to believe companies are going to be running / owning their own servers for a long time to come even if the public cloud guys take over a number of compute workloads.  The Nimbula guys built EC2 and they’re no dummies, so if they believe in this, there must be something to it.

-  There are two kinds of clouds – real and virtual.  Real clouds are multi-tenant. Virtual clouds are not. Virtualization is an amazing technology but it can’t compete with bottoms up multi-tenant platforms and apps.

Stop!  Let me off this merry go-round and let’s talk.

What It Is and Why Multitenancy Matters

Sorry Josh, but Multitenancy isn’t marketing like Intel Inside (BTW, do you notice Intel wound up everywhere anyway?  That wasn’t marketing either), and it matters to more than just vendors.  Why?

Push aside all of the partisan definitions of multitenancy (all your customers go in the same table or not).   Let’s look at the fundamental difference between virtualization and multitenancy, since these two seem to be fighting it out.

Virtualization takes multiple copies of your entire software stack and lets them coexist on the same machine.  Whereas before you had one OS, one DB, and one copy of your app, now you may have 10 of each.  Each of the 10 may be a different version entirely.  Each may be a different customer entirely, as they share a machine.  For each of them, life is just like they had their own dedicated server.  Cool.  No wonder VMWare is so successful.  That’s a handy thing to do.

Multitenancy is a little different.  Instead of 10 copies of the OS, 10 copies of the DB, and 10 copies of the app, it has 1 OS, 1 DB, and 1 app on the server.  But, through judicious modifications to the app, it allows those 10 customers to all peacefully coexist within the app just as though they had it entirely to themselves.

Can you see the pros and cons of each?  Let’s start with cost.  Every SaaS vendor that has multitenancy crows about this, because its true.  Don’t believe me?  Plug in your VM software, go install Oracle 10 times across 10 different virtual machines.  Now add up how much disk space that uses, how much RAM it uses when all 10 are running, and so on.  This is before you’ve put a single byte of information into Oracle or even started up an app.  Compare that to having installed 1 copy of Oracle on a machine, but not putting any data into it.  Dang!  That VM has used up a heck of a lot of resources before I even get started!

If you don’t think that the overhead of 10 copies of the stack has an impact on TCO, you either have in mind a very interesting application + customer combination (some do exist, and I have written about them), or you just don’t understand.  10x the hardware to handle the “before you put in data” requirements are not cheap.  Whatever overhead is involved in making that more cumbersome to automate is not cheap.  Heck, 10x more Oracle licenses is very not cheap.  I know SaaS companies who complain their single biggest ops cost is their Oracle licenses. 

However, if all works well, that’s a fixed cost to have all those copies, and you can start adding data by customers to each virtual Oracle, and things will be okay from that point on.  But, take my word for it, there is no free lunch.  The VM world will be slower and less nimble to share resources between the different Virtual Machines than a Multitenant App can be.  The reason is that by the time it knows it even needs to share, it is too late.  Shifting things around to take resource from one VM and give it to another takes time.  By contrast, the Multitenant App knows what is going on inside the App because it is the App.  It can even anticipate needs (e.g. that customer is in UK and they’re going to wake up x hours before my customers in the US, so I will put them on the same machine because they mostly use the machine at different times).

So, no, there is not some magic technology that will make multitenant obsolete.  There may be some new marketing label on some technology that makes multitenancy automatic and implicit, but if it does what I describe, it is multitenant.  It will age gracefully for a long time to come despite the indignities that petty competition and marketing labels will bring to bear on it.

What’s the Relationship of Clouds and Multitenancy?

Must Real Clouds be Multitenant?

Sorry, but Real Clouds are not Multitenant because they’re based on Virtualization not Multitenancy in any sense such as I just defined.  In fact, EC2 doesn’t share a core with multiple virtual machines because it can’t.  If one of the VM’s started sucking up all the cycles, the other would suffer terrible performance and the hypervisors don’t really have a way to deal with that.  Imagine having to shut down one of the virtual machines and move it onto other hardware to load balance.  That’s not a simple or fast operation.  Multi-tasking operating systems expect a context switch to be as fast as possible, and that’s what we’re talking about.  That’s part of what I mean by the VM solution being less nimble.  So instead, cores get allocated to a particular VM.  That doesn’t mean a server can’t have multiple tenants, just that at the granularity of a core, things have to be kept clean and not dynamically moved around. 

Note to rocket scientists and entrepreneurs out there–if you could create a new hardware architecture that was really fast at the Virtual Machine load balancing, you would have a winner.  So far, there is no good hardware architecture to facilitate a tenant swap inside a core at a seamless enough granularity to allow the sharing.  In the Multicore Era, this would be the Killer Architecture for Cloud Computing.  If you get all the right patents, you’ll be rich and Intel will be sad.  OTOH, if Intel and VMWare got their heads together and figured it out, it would be like ole Jack Burton said, “You can go off and rule the universe from beyond the grave.”

But, it isn’t quite so black and white.  While EC2 is not multitenant at the core level, it sort of is at the server level as we discussed.  And, services like S3 are multitenant through and through.  Should we cut them some slack?  In a word, “No.”  Even though an awful lot of the overall stack cost (network, cpu, and storage) is pretty well multitenant, I still wind up installing those 10 copies of Oracle and I still have the same economic disadvantage as the VM scenario.  Multitenancy is an Application characteristic, or at the very least, a deep platform characteristic.  If I build my app on Force.com, it is automatically multitenant.  If I build it on Amazon Web Services, it is not automatic.

But isn’t there Any Multitenant-like Advantage to the Cloud?  And how do Public and Private Compare?

Yes, there are tons of benefits to the Cloud, and through an understanding and definition of them, we will tease out the relationship of Public and Private Clouds.  Let me explain…

There are two primary advantages to the Cloud:  it is a Software Service and it is Elastic.  If you don’t have those advantages, you don’t have a Cloud.  Let’s drill down.

The Cloud is a Software Service, first and foremost.  I can spin up and control a server entirely through a set of API’s.  I never have to go into a Data Center cage.  I never have to ask someone at the Data Center to go into the Cage (though that would be a Service, just not a Software Service, an important distinction).  This is powerful for basically the same reasons that SaaS is powerful versus doing it yourself with On-prem software.  Think Cloud = SaaS and Data Center = On Prem and extrapolate and you’ll have it. 

Since Cloud is a standardized service, we expect all the same benefits as SaaS:

- They know their service better than I do since it is their whole business.  So I should expect they will run it better and more efficiently.

- Upgrades to that service are transparent and painless (try that on your own data center, buddy!).

- When one customer has a problem, the Service knows and often fixes it before the others even know it exists.  Yes Josh, there is value in SaaS running everyone on the same release.  I surveyed Tech Support managers one time and asked them one simple question:  How many open problems in your trouble ticketing system are fixed in the current release?  The answers were astounding–40 to 80%.  Imagine a world where your customers see 40 to 80% fewer problems.  It’s a good thing!

- That service has economic buying power that you don’t have because it is aggregated across many customers.  They can get better deals on their hardware and order so much of it that the world will build it precisely to their specs.  They can get stuff you can’t, and they can invest in R&D you can’t.  Again, because it is aggregated across many customers.  A Startup running in the Amazon Cloud can have multipe redundant data centers on multiple continents.  Most SaaS companies don’t get to building multiple data centers until they are way past having gone public. 

-  Because it is a Software Service, you can invest your Ops time in automation, rather than in crawling around Data Center cages.  You don’t need to hire anyone who knows how to hot swap a disk or take a backup.  You need peeps who know how to write automation scripts.  Those scripts are a leveragable asset that will permanently lower your costs in a dramatic way.  You have reallocated your costs from basic Data Center grubbing around (where does this patch cable go, Bruce?), an expense, to actually building an asset.

The list goes on.

The second benefit is Elasticity.  It’s another form of aggregation benefit.  They have spare capacity because everyone doesn’t use all the hardware all the time.  Whatever % isn’t utilized, it is a large amount of hardware, because it is aggregated.  It’s more than you can afford to have sitting around idle in your own data center.  Because of that, they don’t have to sell it to you in perpetuity.  You can rent it as you need it, just like eBay does for bursting.  There are tons of new operational strategies that are suddenly available to you by taking advantage of Elasticity.

Let me give you just one.  For SaaS companies, it is really easy to do Beta Tests.  You don’t have to buy 2x the hardware in perpetuity.  You just need to rent it for the duration of the Beta Test and every single customer can access their instance with their data to their heart’s content.  Trust me, they will like that.

What about Public Versus Private Clouds?

Hang on, we’re almost there, and it seems like it has been a worthwhile journey.

Start with, “What’s a Private Cloud?”  Let’s take all the technology of a Public Cloud (heck, the Nimbulla guys built EC2, so they know how to do this), and create a Private Cloud.  The Private Cloud is one restricted to a single customer.  It’d be kind of like taking a copy of Salesforce.com’s software, and installing it at Citibank for their private use.  Multitenant with only one tenant.  Do you hear the sound of one hand clapping yet?  Yep, it hurts my head too, just thinking about it.  But we must.

Pawing through the various advantages we’ve discussed for the Cloud, there are still some that accrue to a Cloud of One Customer:

-  It is still a Software Service that we can control via API’s, so we can invest in Ops Automation.  In a sense, you can spin up a new Virtual Data Center (I like that word better than Private Cloud, because it’s closer to the truth) on 10 minutes notice.  No waiting for servers to be shipped.  No uncrating and testing.  No shoving into racks and connecting cables.  Push a button, get a Data Center.

-  You get the buying power advantages of the Cloud Vendor if they supply your Private Cloud, though not if you buy software and build  your Private Cloud.  Hmmm, wonder what terminology is needed to make that distinction?  Forrester says it’s either a Private Cloud (company owns their own Cloud) or a Hosted Virtual Private Cloud.  Cumbersome.

But, and this is a huge one, the granularity is huge, and there is way less Elasticity.  Sure, you can spin up a Data Center, but depending on its size, it’s a much bigger on/off switch.  You likely will have to commit to buy more capacity for a longer time at a bigger price in order for the Cloud Provider to recoup giving you so much more control.  They have to clear other customers away from a larger security zone before you can occupy it, instead of letting your VM’s commingle with other VM’s on the same box.  You may lose the more multitenant-like advantages of the storage cluster and the network infrastructure (remember, only EC2 was stuck being pure virtual). 

What Does it All Mean, and What Should My Company Do?

Did you see Forrester’s conclusion that most companies are not yet ready to embrace the Cloud and won’t be for a long time?

I love the way Big Organizations think about things (not!).  Since their goal is preservation of wealth and status, it’s all about risk mitigation whether that is risk to the org or to the individual career.  A common strategy is to take some revolutionary thing (like SaaS, Multitenancy, or the Cloud), and break it down into costs and benefits.  Further, there needs to be a phased modular approach that over time, captures all the benefits with as little cost as possible.  And each phase has to have a defined completion so we can stop, evaluate whether we succeeded, celebrate the success, punish those who didn’t play the politics well enough, check in with stakeholders, and sing that Big Company Round of Kumbaya.  Yay!

In this case, we have a 5 year plan for CIO’s.  Do you remember anything else, maybe from the Cold War, that used to work on 5 year plans?  Never mind.

It asserts that before you are ready for the Cloud, you have to cross some of those modular hurdles:

A company will need a standardized operating procedure, fully-automated deployment and management (to avoid human error) and self-service access for developers. It will also need each of its business divisions – finance, HR, engineering, etc – to be sharing the same infrastructure.  In fact, there are four evolutionary stages that it takes to get there, starting with an acclimation stage where users are getting used to and comfortable with online apps, working to convince leaders of the various business divisions to be guinea pigs. Beyond that, there’s the rollout itself and then the optimization to fine-tune it.

Holy CYA, Batman!  Do you think eBay spent 5 years figuring out whether it could benefit from bursting to the Cloud before it just did it?

There’s a part of me that says if your IT org is so behind the times it needs 5 years just to understand it all, then you should quit doing anything on-premise and get it all into the hands of SaaS vendors.  They’re already so far beyond you that they must have a huge advantage.  There is a another part that says, “Gee guys, you don’t have to be able to build an automobile factory as good as Toyota to be able to drive a car.”

But then sanity and Political Correctness prevail, I come back down to Earth, and I realize we are ready to summarize.  There are 4 levels of Cloud Maturity (Hey, I know the Big Co IT Guys are feeling more comfortable already, they can deal with a Capability and Maturity Model, right?):

Level 1:  Dabbling.  You are using some Virtualization or Cloud technology a little bit at your org in order to learn.  You now know what a Machine Image is, and you have at least seen a server that can run them and swapped a few in and out so that you experience the pleasures of doing amazing things without crawling around the Data Center Cage.

Level 2:  Private Cloud.  You were impressed enough by Level 1 that you want the benefits of Cloud Technology for as much of your operation as you can as fast as you can get it.  But, you are not yet ready to relinquish much of any control.  For Early Level 2, you may very well insist on a Private Cloud you own entirely.  Later stage Level 2 and you will seek a Hosted Virtual Private Cloud.

Level 3:  Public Cloud.  This has been cool, but you are ready to embrace Elasticity.  You tripped into it with a little bit of Bursting like eBay, but you are gradually realizing that the latency between your Data Center and the Cloud is really painful.  To fix that, you went to a Hosted Virtual Private Cloud.  Now that your data is in that Cloud and Bursting works well, you are realizing that the data is already stepping outside your Private Cloud pretty often anyway.  And you’ve had to come to terms with it.  So why not go the rest of the way and pick up some Elasticity?

Level 4:  SaaS Multitenant.  Eventually, you conclude that you’re still micromanaging your software too much and it isn’t adding any value unique to your organization.  Plus, most of the software you can buy and run in your Public Cloud world is pretty darned antiquated anyway.  It hasn’t been rearchitected since the late 80’s and early 90’s.  Not really.  What would an app look like if it was built from the ground up to live in the Cloud, to connect Customers the way the Internet has been going, to be Social, to do all the rest?  Welcome to SaaS Multitenant.  Now you can finally get completely out of Software Operations and start delivering value.

BTW, you don’t have to take the levels one at a time.  It will cost you a lot more and be a lot more painful if you do.  That’s my problem with the Forrester analysis.  Pick the level that is as far along as you can possibly stomach, add one to that, and go.  Ironically, not only is it cheaper to go directly to the end game, but each level is cheaper for you on a wide scale usage basis all by itself.  In other words, it’s cheaper for you to do Public Cloud than Private Cloud.  And it’s WAY cheaper to go Public Cloud than to try Private Cloud for a time and then go Public Cloud.  Switching to a SaaS Multitenant app is cheaper still.

Welcome to crazy world of learning how to work and play well together when efficiently sharing your computing resources with friends and strangers!

Posted in amazon, cloud, data center, ec2, enterprise software, grid, multicore, platforms, saas, service | 14 Comments »

Minimizing the Cost of SaaS Operations

Posted by Bob Warfield on March 29, 2010

SaaS software is much more dependent on being run by the numbers than conventional on-premises software because the expenses are front loaded and the costs are back loaded.  SAP learned this the hard way with its Business By Design product, for example.  If you run the numbers, there is a high degree of correlation between low-cost of delivering the service and high growth rates among public SaaS companies.  It isn’t hard to understand–every dollar spent delivering the service is a dollar that can’t be spent to find new customers or improve the service.

So how do you lower your cost to deliver a SaaS service? 

At my last gig, Helpstream, we got our cost down to 5 cents per seat per year.  I’ve talked to a lot of SaaS folks and nobody I’ve yet met got even close.  In fact, they largely don’t believe me when I tell them what the figures were.  The camp that is willing to believe immediately wants to know how we did it.  That’s the subject of this “Learnings” blog post.  The formula is relatively complex, so I’ll break it down section by section, and I’ll apologize up front for the long post.

Attitude Matters:  Be Obsessed with Lowering Cost of Service

You get what you expect and inspect.  Never a truer thing said than in this case.  It was a deep-seated part of the Helpstream culture and strategy that Cost of Service had to be incredibly low.  So low that we could exist on an advertising model if we had to.  While we never did, a lot was invested in the critical up front time when it mattered to get the job done.  Does your organization have the religion about cutting service cost, or are there 5 or 6 other things that you consider more important?

Go Multi-tenant, and Probably go Coarse-grained Multi-tenant

Are you betting you can do SaaS well enough with a bunch of virtual machines, or did you build a multi-tenant architecture?  I’m skeptical about your chances if you are in the former camp unless your customers are very very big.  Even so, the peculiar requirements of very big customers (they will insist on doing things their way and you will cave) will drive your costs up.

Multi-tenancy lets you amortize a lot of costs so that they’re paid once and benefit a lot of customers.  It helps smooth loads so that as one customer has a peak load others probably don’t.  It clears the way to massive operations automation which is much harder in a virtual machine scenario.

Multi-tenancy comes in a lot of flavors.  For this discussion, let’s consider fine-grained versus coarse-grained.  Fine grain is the Salesforce model.  You put all the customers together in each table and use a field to extract them out again.  Lots of folks love that model, even to a religious degree that decrees only this model is true multi-tenancy.  I don’t agree.  Fine grained is less efficient.  Whoa!  Sacrilege!  But true, because you’re constantly doing the work of separating one tenant’s records from another.  Even if developers are protected from worrying about it by clever layering of code, it can’t help but require more machine resources to constantly sift records.

Coarse-grained means every customer gets their own database, but these many databases are all on the same instance of the database server.  This is the model we used at Helpstream.  It turns out that a relatively vanilla MySQL architecture can support thousands of tenants per server.  That’s plenty!  Moreover, it requires less machine resources and it scales better.  A thread associated with a tenant gets access to the one database right up front and can quit worrying about the other customers right then.  A server knows that the demands on a table only come from one customer and it can allocate cpus table by table.  Good stuff, relatively easy to build, and very efficient.

The one down side of coarse grain I have discovered is that its hard to analyze all the data across customers because it’s all in separate tables.  Perhaps the answer is a data warehouse constructed especially for the purpose of such analysis that’s fed from the individual tenant schemas.

Go Cloud and Get Out of the Datacenter Business

Helpstream ran in the Amazon Cloud using EC2, EBS, and S3.  We had help from OpSource because you can’t run mail servers in the Amazon Cloud–the IP’s are already largely black listed due to spammers using Amazon.  Hey, spammers want a low-cost of ops too!

Being able to spin up new servers and storage incrementally, nearly instantly (usually way less than 10 minutes for us to create a  new multi-tenant “pod”), and completely from a set of API’s radically cuts costs.  Knowing Amazon is dealing with a lot of the basics like the network infrastructure and replicating storage to multiple physical locations saves costs.  Not having to crawl around cages, unpack servers, or replace things that go bad is priceless. 

Don’t mess around.  Unless your application requires some very special hardware configuration that is unavailable from any Cloud, get out of the data center business.  This is especially true for small startups who can’t afford things like redundant data centers in multiple locations.  Unfortunately, it is a hard to impossible transition for large SaaS vendors that are already thoroughly embedded in their Ops infrastructure.  Larry Dignan wrote a great post capturing how Helpstream managed the transition to Amazon.

Build a Metadata-Driven Architecture

I failed to include this one in my first go-round because I took it for granted people build Metadata-driven architectures when they build Multi-tenancy.  But that’s only partially true, and a metadata-driven architecture is a very important thing to do.

Metadata literally means data about data.  For much of the Enterprise Software world, data is controlled by code, not data.  Want some custom fields?  Somebody has to go write some custom code to create and access the fields.  Want to change the look and feel of a page?  Go modify the HTML or AJAX directly.

Having all that custom code is anathema, because it can break, it has to be maintained, its brittle and inflexible, and it is expensive to create.  At Helpstream, we were metadata happy, and proud of it.  You could get on the web site and provision a new workspace in less than a minute–it was completely automated.  Upgrades for all customers were automated.  A tremendous amount of customization was available through configuration of our business rules platform.  Metadata gives your operations automation a potent place to tie in as well.

Open Source Only:  No License Fees!

I know of SaaS businesses that say over half their operating costs are Oracle licenses.  That stuff is expensive.  Not for us.  Helpstream had not a single license fee to pay anywhere.  Java, MySQL, Lucene, and a host of other components were there to do the job.

This mentality extends to using commodity hardware and Linux versus some fancy box and an OS that costs money too.  See for example Salesforce’s switch.

Automate Operations to Death

Whatever your Operations personnel do, let’s hope it is largely automating and not firefighting.  Target key areas of operational flexibility up front.  For us, this was system monitoring, upgrades, new workspace provisioning, and the flexibility to migrate workspaces (our name for a single tenant) to different pods (multi-tenant instances). 

Every time there is a fire to be fought, you have to ask several questions and potentially do more automation:

1.  Did the customer discover the problem and bring it to our attention?  If so, you need more monitoring.  You should always know before your customer does.

2.  Did you know immediately what the problem was, or did you have to do a lot of digging to diagnose?  If you had to do digging, you need to pump up your logging and diagnostics.  BTW, the most common Ops issue is, “Your service is too slow.”  This is painful to diagnose.  It is often an issue with the customer’s own network infrastructure for example.  Make sure to hit this one hard.  You need to know how many milliseconds were needed for each leg of the journey.  We didn’t finish this one, but were actively thinking of implementing capabilities like Google uses to tell with code at the client when a page seems slow.  Our pages all carried a comment that told how long it took at the server side.  By comparing that with a client side measure of time, we would’ve been able to tell whether it was “us” or “them” more easily.

3.  Did you have to perform a manual operation or write code to fix the problem?  If so, you need to automate whatever it was.

This all argues for the skillset needed by your Ops people, BTW.  It also argues to have Ops be a part of Engineering, because you can see how much impact there is on the product’s architecture.

Hit the Highlights of Efficient Architecture

Without going down the rathole of premature optimization, there is a lot of basic stuff that every architecture should have.  Thread pooling.  Good clean multi-threading that isn’t going to deadlock.  Idempotent operations and good use of transactions with rollback in the face of errors.  Idempotency means if the operation fails you can just do it again and everything will be okay.  Smart use of caching, but not too much caching.  How does your client respond to dropped connections?  How many round trips does the client require to do a high traffic page?

We used Java instead of one of the newer slower languages.  Sorry, didn’t mean to be pejorative, and I know this is a religious minefield, but we got value from Java’s innate performance.  PHP or Python are pretty cool, but I’m not sure they are what you want to squeeze every last drop of operations cost out of your system.  The LAMP stack is cheap up front, but SaaS is forever.

Carefully Match Architecture with SLA’s

The Enterprise Software and IT World is obsessed with things like failover.  Can I reach over and unplug this server and automatically failover to another server without the users ever noticing?  That’s the ideal.  But it may be a premature optimization for your particular application.  Donald Knuth says, “97% of the time: premature optimization is the root of all evil.” 

Ask yourself how much is enough?  We settled on 10 minutes with no data loss.  If our system crashed hard and had to be completely restarted, it was good enough if we could do that in less than 10 minutes and no loss of data during that time.  That meant no failover was required, which greatly simplified our architecture. 

To implement this, we ran a second MySQL replicated from the main instance and captured EBS backup snapshots from that second server.  This took the load of snapshotting off the main server and gave us a cheaper alternative to a true full failover.  If the main server died, it could be brought back up again in less than 10 minutes with the EBS volume mounted and away we would go.  The Amazon infrastructures makes this type of architecture easy to build and very successful.  Note that with coarse-grained multi-tenancy, one could even share the backup server across multiple multi-tenant instances.

Don’t Overlook the Tuning!

Tuning is probably the first thing you thought of with respect to cutting costs, right?  Developers love tuning.  It’s so satisfying to make a program run faster or scale better.  That’s probably because it is an abstract measure that doesn’t involve a customer growling about something that’s making them unhappy.

Tuning is important, but it is the last thing we did.  It was almost all MySQL tuning too.  Databases are somewhat the root of all evil in this kind of software, followed closely by networks and the Internet.  We owe a great debt of gratitude to the experts at Percona.  It doesn’t matter how smart you are, if the other guys already know the answer through experience, they win.  Percona has a LOT of experience here, folks.

Conclusion

Long-winded, I know.  Sorry about that, but you have to fit a lot of pieces together to really keep the costs down.  The good news is that a lot of these pieces (metadata-driven architecture, cloud computing, and so on) deliver benefits in all sorts of other ways besides lowering the cost to deliver the service.  Probably the thing I am most proud of about Helpstream was just how much software we delivered with very few developers.  We never had more than 5 while I was there.  Part of the reason for that is our architecture really was a “whole greater than the sum of its parts” sort of thing.  Of course a large part was also that these developers were absolute rock stars too!

Posted in cloud, data center, ec2, enterprise software, platforms, saas, software development | 5 Comments »

Does the Cloud make Single-Tenancy OK for SaaS?

Posted by Bob Warfield on April 15, 2009

Multi-tenancy and all its flavors seems to be on people’s minds lately.  I just finished going back and forth with Phil Wainewright on some of the nuances of multi-tenancy and how it impacts the cost model for SaaS.  Phil’s post was on some of the sophisticated nuances of multi-tenancy as expressed by some of the latest announcements from the SaaS Vatican, Salesforce.com.

More recently, it has come to my attention both through my fellow bloggers of the Enterprise Irregulars as well as via a trackback to my blog post that there are those who are now saying the Cloud has made the world safe for SaaS vendors to forget multi-tenancy and plunge ahead with single-tenancy.

Not so fast! 

Color me skeptical.  If you don’t have a multi-tenant architecture, you’re going to argue it isn’t necessary.  That doesn’t make it right.  Before we get too far along, let me define multi-tenancy:

Multi-tenancy is a software architecture that allows multiple tenants to be hosted on a single box (or cluster of boxes) just as easily and economically as a single tenant could be hosted on the same configuration.

The bloggers taking the position that single tenancy is good enough hoist a variety of flags in support of their position, but for me, it boils down to answering one simple question about your SaaS business and its customers:

Fundamentally, do you have an application that can successfully run multiple tenants on a single box or not? 

If a single box has enough horsepower to run multiple customers for your app, the argument for single-tenant is completely (pardon my near-pun) untenable.
 
Salesforce runs 55,000 customers on 1,000 commodity servers.  You just aren’t going to be able to do that with a single tenant architecture no matter how much virtualization you choose to run.  If nothing else, virtualization runs afoul of a fixed cost/variable cost phenomenon very quickly.  A lot of the basic system software allocates fixed overhead, whether we’re talking about your DB server, your app server, your web server, or whatever.  Virtualization does not share the resources required for the fixed overhead, only the the variable costs.  Multitenant shares the fixed overhead too.  Those variable costs put an upper limit on the number of tenants you can shove onto a single box, no matter how small the tenant’s needs may be.
 
The new articles maintain that the Cloud fixes all this through the magic of elasticity.  Really?  That’s hogwash.  The Cloud at best and if you really architected your app to take full advantage of elasticity may help a little bit.  But most of the problem is database, and elasticity and databases so far remain a very hard technical problem to solve.  Try dynamically varying your partitioning and/or federation scheme to really scale up and down in real time in the Cloud.  It’s hard enough to get apps to scale to arbitrary Enterprise needs at all.  Try doing that in real time so you get multitenant cost savings?  Good luck!
 
So if you can’t run an average of 55 customers on each of 1000 servers like Salesforce, how many can you run without multitenant?  3?  5?  10?  What does that do to your cost versus true multitenant?  What does that do to the overhead of maintaining the servers?  What does that do to your cost of delivering the service and to the resultant cost model you have to saddle you customers with?  What does that do to you competively if you’re up against a company that does have the true multitenant cost advantage?
 
One example on the cost subject that I am familiar with:  a lot of the Social Software companies wind up charging by page views or total participant seats.  In many ways, this is anathema to community where you should do everything you can to encourage participation and not penalize it.  This is especially true for outwardly facing communities where the company wants a predictable cost model and can’t imagine being charged by their continually changing customer base or especially the changing usage patterns of that base.
 
In fairness, there are some business model + company + market + architecture combinations where it wouldn’t matter because you can’t run multiples on a single box.  If you’re strictly selling to organizations that can’t run on a single box no matter what, single tenant is fine.  Perhaps this is what these other bloggers are saying, but I’m skeptical any Enterprise 2.0 app would have that requirement, and that’s the kind of software these bloggers are describing.  FWIW, Helpstream will run 150 customers and nearly 400K seats on a single box loaded to about 10% of capacity.  That’s nothing though.  Look to the Googles, Facebooks, Amazons, eBays, Twitters, and similar big web properties to see real capacity.  Now combine that kind of capacity with multiple tenants.  It is a powerful competitive position to be in.

As I say, one can imagine combinations where you couldn’t combine multiple tenants onto a single box.  A honking big transaction processing ERP app might be one.  For another, at Callidus, I had customers using as many as 150 CPU’s to generate all the sales commission calculations for a huge salesforce.  To give an idea, we had telcos paying 20K sales reps and insurance companies paying 250K reps.  That’s a lot of transactions paid to a lot of people!  But those kind of Enteprise deals are very unusual for SaaS companies, and that kind of app is pretty unusual too because of the number of transactions being processed and the complexity of the business logic.  Still, such apps could be successful in those markets with single tenancy.
 
The articles go on to talk about the advantages of being able to customize these multiple instances.  Frankly, that scares me too, because the whole SaaS model really starts to break apart there when you decide to radically customize each instance.  It may be a value add, but it is a radically different value add than SaaS.  In fact, at that point, it’s a hosted ASP model, not SaaS.  Useful for some organizations, but there is a reason that model never achieved broad market appeal. 
 
Lastly, let’s talk about the whole security business.  This is the 800lb Red Herring in the room.  The minute you go SaaS or Cloud, you have outsourced that problem.  You can listen to vendors argue all day long about which architecture is “safer”, but that is an over simplification of the myriad factors that matter to the point it is just marketing and not substance.  It has as much to do with process as code architecture, which is why most of the security related standards like SAS70 and HIPAA don’t spend a lot of time on software architecture so much as the processes that surround that software.  Don’t take my word for it.  Look at what happened to Amazon around the whole AmazonFail incident for lack of process on an area that didn’t even involve any code.  Their problem was due to a data change.

BTW, the multi-tenancy imperative gets stronger constantly due to the multicore crisis.  We no longer get faster cpus (i.e. faster clock speeds) every 18 months according to Moore’s Law.  Instead, we get twice as many cores.  The easiest way to take advantage of more cores?  You guessed it: stack more tenants into the same box. 

For more, read Michael Dunham’s excellent post over on Haut Tec.

Posted in cloud, enterprise software, saas | 12 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 323 other followers

%d bloggers like this: