SmoothSpan Blog

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

Archive for the ‘enterprise software’ Category

« Previous Entries

Oh Dear, the Green Pundits Don’t Understand the Cloud or Multitenancy

Posted by Bob Warfield on January 16, 2015

forestRecently I was drawn into a discussion of how Green the Cloud is where I responded as follows:

SaaS is going to come out ahead of any reasonably calculation of carbon emissions versus on-prem. Multi-tenancy is just a lot more efficient. Look at the data centers of companies like Google, Amazon, and Facebook. Most corporates wish they could come close as they watch these companies dictate every detail right down to the exact design of servers in order to minimize their costs. As everyone agrees, most of that cost is energy.

So choose SaaS if you’re worried about carbon, and yes, it could become another axis of competition in terms of exactly which Cloud provider does it best.

Tom Raftery immediately responded:

The answer is that it depends, tbh. It depends entirely on the carbon intensity of the data centre (where it sources its energy), not the efficiency of the data centre.

If you have a data centre with a PUE of 1.2, and it is 50% coal powered (not atypical in North America, Germany, Poland, and others, for example), it will have a higher CO2 footprint than a data centre with a PUE of 3.0 powered primarily by renewables – again I have run the numbers on this and published them.

Similarly with on-prem. If I have an app that I’m running in-house, and I’m based in a country like Spain, France, Denmark, or any other country with where the electricity has a low carbon intensity; then moving to the cloud would likely increase the CO2 footprint of my application. Especially if the cloud provider is based in the US which has 45% of its electricity generated from coal.

Tom is the chief analyst for Greenmonk, which writes about this sort of thing for a living.  He’s been quoted by others who are in the same camp such as Brian Proffitt on ReadWriteWeb.  And who wouldn’t love a nice juicy story to put those darned Cloud vendors in their place?  Those guys have been riding high for too long and ought to be brought down a notch or two, harrumph.

I have a lot of problems with this kind of math–it just doesn’t tell the whole story.

First, I can’t imagine why Tom wants to be on record as saying that PUE (Power Usage Efficiency) just doesn’t matter.  Sure, he has found some examples where CO2 footprint overwhelmed PUE, but to say the answer depends entirely (his word) on the sources of the data center’s energy and not on the efficiency of the data center just seems silly to me.  Are there no data centers anywhere in the world at all where PUE matters?  Did all the Cloud data centers with great PUE just magically get situated where the carbon footprints are lousy enough that PUE can’t matter?

I’m very skeptical that could be the case.  You must consider both PUE and CO2 per Kilowatt Hour, how could we not when we’re talking per Kilowatt hour and PUE determines how many Kilowatts are required?

Here’s another one to think about.  If this whole PUE/CO2 thing matters enough to affect the economics of a Cloud Vendor, we should expect them to build data centers in regions with better CO2 energy.  Since they put up new data centers constantly, that’s not going to take them very long at all.  Some are talking about adding solar to existing facilities as well.  Now, do we want to lay odds that corporate data centers are going to be rebuilt and applications transferred as quickly for the same reasons?  If you’re running corporate IT and you have a choice of selecting a Cloud Data Center with better numbers or building out a new data center yourself, which one will get you the results faster?  And remember, once we are comparing Apples to Apples on CO2, those Cloud vendors’ unnaturally low PUE’s are going to start to haunt you even more as they run with fewer Kilowatt Hours.

Multitenancy Trumps all this PUE and CO2 Talk

But there’s a bigger problem here in that all data centers are not equal in another much more important way than either PUE or fuel source CO2 footprints.  That problem is multitenancy.  In fact, what we really want to know is CO2 emissions per seat served–that’s the solution everyone is buying.  Data centers get built in order to deliver seats of some application or another, they’re a means to an end, and delivering seats is that end.  The capacity they need to have, the number and type of servers, and hence the ultimate kilowatts consumed and carbon footprint produced is a function of seats.  Anyone looking purely at data centers and not seats served is not seeing the whole picture.  After all, if I run a corporation that has a datacenter, it’s fair to charge the carbon from that datacenter against my corporation.  But if I am subscribing to some number of seats of some Cloud application, I should only be charged the carbon footprint needed to deliver just those seats.  Why would I pay the carbon footprint needed to deliver seats to unrelated organizations?  I wouldn’t.

Corporate data centers have been doing better over time with virtualization at being more efficient.  They get a lot more seats onto a server than they used to.  The days of having a separate collection of hardware for each app are gone except for the very most intensive apps.  But that efficiency pales in comparison to true multitenancy.  If you wonder why, read my signature article about it.  I’ll run it down quickly here too.

Consider using virtual machines to run 10 apps.  Through the magic of the VM, we can install 10 copies of the OS, 10 copies of the Database Server, and 10 copies of the app.  Voila, we can run it all on one machine instead of 10.  That’s pretty cool!  Now what does Multitenancy do that the VM’s have to compete with?  Let’s try an example where we’re trying to host the same software for 10 companies using VM’s.  We do as mentioned and install the 10 copies of each kind of software and now we can host 10 tenants.  But, with multitenancy, we install 1 copy of the OS, 1 copy of the Database, and 1 copy of the app.  Then we run all 10 users in the same app.  In fact, with the savings we get from not having to run all the VM’s, we can actually hose more like 1000 tenants versus 10.

But it gets better.  With the Virtual Machine solution, we will need to make sure each VM has enough resources to support the peak usage loads that will be encountered.  There’s not really a great way to “flex” our usage.  With Multitenancy, we need to have a machine that supports the peak loads of the tenants at any moment in time on the system.  We can chose to bring capacity on and off line at will, and in fact, that’s our business.  For a given and very large number of seats, larger than most any single corporate application for most corporations, would we rather bet the corporation can be more efficient with on-prem software in its wholly owned data center or that the SaaS vendor will pull off far greater efficiency given that its software is purpose-built to do so?  My bet is on the SaaS vendor, and not by a little, but by a lot.  The SaaS vendor will beat the corporate by a minimum of 10-20x and more likely 100x on this metric.  You only have to look to the financials of a SaaS company to see this.  Their cost to deliver service is a very small part of their overall expenses yet most SaaS apps represent a considerable savings over the cost of On-Prem even though they carry the cost of delivering the service which the On-Prem vendor does not.

Conclusion

Raftery says, “energy use” and “emissions produced” have been conflated to mean the same thing.  I say he’s absolutely right about that but hasn’t seen the bigger picture that it is not energy use nor emissions produced in isolation, it’s seats delivered per emissions produced.  Itt’s having the flexibility to make a difference rapidly.  And that is why we bet on the Cloud when it comes to being Green.

Posted in cloud, data center, enterprise software, saas, strategy | 1 Comment »

Secrets of When and How to Talk to Customers at a Startup

Posted by Bob Warfield on October 9, 2014

elephant-with-blind-menJason Lemkin says forget building wireframe UI’s and start out interviewing 20 customers, because you just won’t understand your customers until you do.  Here’s the gist of why you need 20 interviews before you do anything else:

And you have to do 20.  I know it’s hard to get to 20.  But it’s the right number:

  • You need the First 5 Interviews just to truly understand the white space and the current opportunity.  Yes, you probably think you already understand it.  But you are the vendor, not the purchaser.  You need to understand your prospective app from the purchaser’s perspective, for real.
  • You need the Next 5 Interviews to confirm your pattern recognition.  You learn from the first 5, you confirm in the next 5.
  • You need Interviews 11-20 to Nail Your Pitch and Hone Your Thesis.  Once you truly understand the white space from a buyer’s perspective, and you’ve figured out the nuances and challenges … it’s time to nail your pitch for real.  And by doing this, you’ll also hone your thesis and strategy.   That’s what interviews 11-20 are.  To get real critical feedback on what you’ve learned.  To learn about corner cases that may in fact be critical insertion points for you to win.  To dig in on what is really 10x better, not just 2x or 5x better.

And let me tell you, at least from my experience, don’t expect all 20 to be positive.  Many of My 20 Interviews in both my start-ups were very critical.  Or worse, lukewarm.  Lukewarm is even worse, because it says yeah it’s sort of interesting … but no way I’d buy … and implicitly … your idea is a huge waste of time.  I’d rather get the negative feedback 😉

I get the Steve Jobs thing.  You just have to build it.  You do.  But this is SaaS.  You’re solving a business’ problem.  They don’t know how to solve it, or what you should build.  But they do now how to express their problem.  Acutely, and thoughtfully.

Here’s the funny thing–in some ways I agree with Jason and in others I totally disagree.  It depends really on what it is you’re trying to learn from your 20 interviews.  Jason says you’re trying to understand the white space and the current opportunity and that you’re trying to nail your pitch and hone your thesis.  He’s thinking about it like a Sales Guy, more power to him, someone in your company ought to be.  But there’s more to life and startups than Sales Guys.

Here is what I worry about validating in the early days of any startup:

1.  What is the problem we’re trying to solve for customers?

2.  Is it a real problem?  Do a large portion of customers believe they have this problem?

3.  Will the solution we’ve imagined actually solve that problem?  Do the customers agree that it solves their problem?  Can we charge enough to make a real business for this solution?

4.  Do we have a pitch that communicates we have a real and effective solution quickly?

I see Jason’s 20 interviews as helping to solve #2 and #4, but not really making much impact on #1 and #3.  Moreover, I see #4 as being pretty tactical, unless, of course, you need that finely honed pitch to convince investors.  It’s tactical because we won’t need it until it’s actually time to get customers to deploy beta product.  In other words, we have quite a lot of time to solve it.  #3 is not so tactical.  In fact, if we don’t solve #3 right up front, we could easily spend the bulk of our time building a product that we think solves the customer’s problem but that customers aren’t confident in.

Let’s drop back and work on each one of these 4 critical questions and see how and when in the startup cycle they should be tackled.

1.  What is the problem we’re trying to solve for customers?

This is a tough one for many entrepreneurs.  I’ve seen a few decide to try to find a hard problem to solve by interviewing potential customers.  What keeps you up at night?  What do you hate about your job?

Ugh.  That seems so hit or miss.  None of the ones I met who’ve tried this got very far with it.  They got problems that software was just simply not the cure for or they got problems that are more conditions of the human race than anything.  Jason says customers, “Know how to express their problem.  Acutely, and thoughtfully.”  Actually, they don’t, not so much.  They know how to resonate with a problem that you’ve stated acutely and thoughtfully.  They know how to resonate when you state a problem as a near miss to how they really think about it.  But customers are not product designers nor company founders for the most part.  They’re severely myopic.  As Henry Ford famously put it,

“If I had asked people what they wanted, they would have said faster horses.”

So don’t rely on customers to tell you what the problem is.  Really on them to confirm you’ve found a problem they feel.  Later, they’ll remember it as you having discovered the problem from them, but that’s not really how it works most of the time.

There are a lot of reasons for this.  The myopia is one but another is they just don’t know much about the medium you work in–software.  They have little idea what software can do for them.  They think of most software in terms of software they already have, which is another form of myopia.

You are not going to figure out that problem, in all likelihood, through a few simply interviews.  You’re going to have to live the life of your customers for a while, walk in their shoes, and feel their pain.  You need to know their domain intimately, which is not something that’s going to happen in 20 interviews, no matter how good they are.  That’s how two great Sales Guys wound up creating two great CRM companies–Tom Siebel with Siebel Systems and Mark Benioff with Salesforce.com.  I interviewed with Tom Siebel when he had less than 20 employees and the one thing that was absolutely clear about the man was that he knew the domain and its problems cold.  That’s the kind of solid domain knowledge you really should have in your startup.  Who can you point to who has lived and breathed the problems and knows them cold?

Is that the only way?

No, there are plenty of exceptions.  There are proxies available too.  Finding a large online community of your desired customer can give you huge insights into what their world is all about.  What do they ask questions about most frequently?  What do they complain about frequently?  These communities are so helpful to startups both for gathering information as well as for getting out the word that I’m not sure I’d want to do a startup that couldn’t identify an online community specializing in its customers.  In this age of Content Marketing, it seems to me that such a community would be a very valuable indicator that the market was going to be reachable and at reasonable costs.  I don’t want to have to advertise or cold call my way into existence, though many have certainly done so.

To put this into the perspective of Jason’s 20 interviews, you need domain knowledge for your startup before anything else.  You won’t get it from the 20 interviews, and it is just table stakes that you have to find.  Maybe you’re counting on a founder for it.  Maybe you have the world’s ultimate advisory board.  Maybe you’ve sold to these poeple in a former life and know all about them.  Maybe you’ve spent a year studying and interacting with their online communities.  Whatever it is, you’d better have it.

 

2.  Is it a real problem?  Do a large portion of customers believe they have this problem?

Having gotten your domain knowledge together, you believe you’ve discovered a real problem.  Now that you can articulate that problem, it’s time to confirm it with potential customers.  Jason’s 20 interviews are perfect for this stage.  I don’t know that there is anything magical about 20 or that this even has to be done via interviews.  If you’re going to be using feet on the street to move your product (e.g. a scratch golfin’ highly paid salesforce), you should probably get started with interviews.  If your Sales Guy can’t line up 20 interviews in his sleep, there is something wrong, so may as well set him to the test.  If you weren’t planning to get a Sales Guy until later and you can’t line up 20 interviews on your own, you better get the Sales Guy sooner.  There’s a lot of good that comes from achieving the 20 interviews and here Jason and I agree wholeheartedly.

But in addition to 20 interviews, I highly recommend a few other things.

One of my mentors has used the method multiple times of creating a web site that’s all about the proposed problem and solution.  He sets it up like there’s a product ready to go, except there’s no way to order it.  You can simply request more information.  He gauges the quality of the idea by whether he can get many information requests.  And yes, he understands the need to do some tuning up before giving up.  This is a case where having online communities of your potential customers is awesome.  If you have a simulacrum site as described (looks like a real company and product), you can ask the folks in the community what they think of the company and idea.

If you don’t like that approach because it just feels a little too funky, try my approach.  I started a blog before I started my current company and I waited to see if I could drive significant traffic to that blog discussing the kinds of problems I wanted to solve.  I would talk about how people were solving their problems today, rather than how I proposed to solve them.  I measured traffic using all of the standard web analytics to see what resonated and what did not.  I built a lot of credibility and I had a following already in place that I leveraged to a significant Beta test and significant cash sales when I was finally ready to launch the product.  But, before I started building the product, I knew from how people were reacting to my writings that I understood the customers and their problems very well.  I achieved what I call “Content-Audience Fit” (a precursor to Product-Market Fit).  More about that below under #3.

 

3.  Will the solution we’ve imagined actually solve that problem?  Do the customers agree that it solves their problem?  Can we charge enough to make a real business with this solution?

Here’s where I probably disagree with Jason the most.  He says, “So if you haven’t started yet, as fun as it is to just build the wireframes and get a codin’ … do the 20 Interviews.”

Here’s my problem–as I’ve mentioned, the Customers really can’t articulate their problem unaided.  They can only resonate with your articulation.  We may have to agree to disagree on that, but figuring out how to resonate well is a huge function for Sales precisely because the customer can’t do it for themselves.  They often need help even in how to present it to each other to get buy-in within their organizations.  When you go interview them, you’re going to get a variation on the three blind men encountering an elephant for the first time.  One touches the trunk, and thinks it’s a snake.  Another touched the tale, and thinks it’s like a straw fan swishing back and forth.  While the third touched the legs and pronounced that elephants are like trees.

When it comes to envisioning a solution, especially in software, things get far worse.  At least they have all experienced the problem, even though it may appear to be a snake, a fan, or a tree.  But nobody outside your company even has a glimmering about your proposed solution.

I’ve done lots of focus groups over the years and lots of the kinds of interviews Jason talks about, and I am here to tell you it is pointless to do either if you expect to get feedback about a software solution unless you have at least some wireframes and storyboards to show.  With modern tools, it’s just not that hard to produce these things.  I’m working on our third product at CNCCookbook.  I was able to put together a UI prototype that is substantially what our finished product will be with about 6 weeks worth of effort.  It’s been hugely valuable in securing feedback for the product and I have learned an awful lot from it.  Perhaps the biggest problem it has is people start to mistake it for a finished solution or they assume it’ll be ready much sooner than it will and they get too excited.  They’re ready to buy immediately.

Yes, it may be fun to build wireframes, but it is also fun to have real meaningful conversations with prospective customers about your proposed solution.  You’re going to learn so much more about everything if you can do that around a real demo.  You’ll learn about positioning, sub-problems and edge cases that as Jason says are critical insertion points to win.  You’ll learn whether your proposed solution really fixes the customer’s problem in their eyes.  You’ll feed on the enthusiasm they have for what they see, and that enthusiasm is valuable fuel for your startup, for convincing critical new hires, and for any potential investors you may have.

If it’s really going to be hard for you to get interviews with 20 real prospective customers, people who are solid citizens in their markets and who are not your buddies.  People who will give you the straight scoop, help guide you, and who you’re hoping will be early adopters.  If it’s that important and that tough, I can’t imagine wanting to do it without bringing along a UI mock up.  It isn’t just my current venture, I have done this at every single one of the 7 startups I’ve been with.  I have done it for every new product release.  It’s actually integral to how I approach the Agile Software experience.

If your Sales Guy can’t get 20 meetings, get another one.  If your Product Guy can’t get you a UI prototype quickly, get another one there too.  Both are equally as important.

One more thing–that last part, “Can we charge enough to make a real business with this solution?”  That’s critically important to answer ASAP.  It’s also nearly impossible to get a very good answer to it without a UI prototype.  Yes, they will give you some answers, but I am talking about real answers that will hold water when it’s time to cash the checks. Don’t you want to know whether customers will pay up for what you’re going to build as early as possible?

 

4.  Do we have a pitch that communicates we have a real and effective solution quickly?

This is what I call “Content-Audience Fit“.  I believe achieving that fit needs to come ahead of finishing the product if for no other reason than that you won’t know if the product is finished nor will you be ready to efficiently leverage content for product traction unless you do.

Jason’s 20 meetings go towards this end, but it’ll take more than 20 to really nail your pitch.  Personally, I don’t like to burn real perspective customers, investors, or other scarce as hen’s teeth resources for a company if I can find another way to test this stuff out and perfect it.  The online world and Content Marketing are your gateway to doing so. Once you can resonate with those audiences, break out the Rolodex (kids you’ll have to look up what that is) and start asking for meetings.  You’ll be bringing to that meeting a laundry list of good-as-gold asssets:

–  By this point you have a UI prototype to demo.

–  You have verified that you can talk about the problem and with the audience with enough credibility that they’re at least starting to come to you for answers.

–  You’ve had the opportunity to test a number of things with your growing audience.  You’ve probably even been able to do some surveys.

–  You have a corpus of content that you can point potential meeting invitees to that helps establish your bona fides and gets the conversation off on the right track.  If done right, this can be a warm call and not a total cold call.

Most importantly, none of this is all that expensive or time consuming.  You can do it on your own nickel without waiting for a Series A VC round.  I know I have more than once.  I’d set a goal of 3-6 months to get to this point.  If everyone is firing on all cylinders, you’re producing good content, you’ve gotten through your UI prototype, and you’ve made contact with a decent sized audience, you’ve accomplished a lot at your startup.  You’re right where you need to be.  Now line up those 20 meetings, get in there and make those 20 people your first Beta tests, and hit the ball out of the park for them.  They’ll love you for it and you’ll have set the stage for your next 6 months as you drive to launching the Beta and eventually real Sales.

Posted in bootstrapping, business, enterprise software, saas, strategy, venture | 1 Comment »

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 | 15 Comments »

« Previous Entries
 
%d bloggers like this: