SmoothSpan Blog

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

Archive for August 31st, 2007

Domain Specific Social Networking, Anyone?

Posted by Bob Warfield on August 31, 2007

While we’re slicing and dicing behavioural aspects of Social Networking, here is another dimension to contemplate:  Domain Specific Social Networking.  The idea comes about as a derivative of Domain Specific Languages.  As the Wikipedia puts it, a Domain Specific Language is a programming language that was created for a specific task (i.e. its “domain”).  I think a nicer name is “problem-oriented language”, but I’m not in charge.  For example, the odd little language GraphViz is used exclusively for creating a particular kind of diagram.

Let me give another related example.  We see quite a few Domain Specific Search Engines.  Spock is for searching about people.  CureHunter is for searching about medicine.  Amazon is for searching for things to buy.  In each case, we can see how the tool is able to do a better job than more generic tools because it incorporates features and knowledge specific to the domain.  In effect, it makes the problem easier because it is focused on a subset.

Back to Domain Specific Social Networking.  I’ll argue that LinkedIn is a DSSN (sorry, got tired of all that typing), while Facebook and MySpace are just Social Networks.  Why?  Because LinkedIn is pretty well tuned to standard business networking activities.  Where is John working these days?  Who do I know at the customer who might help me out selling?  We need to hire a great web designer, who can we find by referral?

What’s the point?  There are a couple, and it really depends on what you are trying to accomplish.  Once again, we have a trade off between “all things to all people” and “exactly the right product for a particular purpose”.  Focus your thinking around what you’re trying to accomplish and think about that trade off.  If you’re creating (or harnessing someone else’s) social network for marketing purposes to “get the word out”, you probably want something pretty general.  OTOH, if you have some specific purpose, perhaps you want to enable collective decision making, you might want to consider some sort of DSSN that is more optimal to your task.

Before leaving this topic, let’s also consider another trick that can help blend general Social Networks with the DSSN concept:  Widgets.  Specialized Widgets are a great way to get a quick and dirty DSSN operating just long enough to solve a particular problem.  A great example of this is Market Research.  An online survey injected into an existing Social Network can get you much-needed decision making input.  What about calls to action?  How about revamping the age old idea of a contest by supercharging it with some Web 2.0 juice?  We can inject a contest that involves giving us something we want.  Perhaps its ideas for new products or some such.  Perhaps its getting people to try your product (take the Pepsi Challenge).  Perhaps you want a guest speaker on your blog, or the most interesting customer success story.  There’s a million ways to think of using contests, surveys, voting, and all the rest to get this done. 

How about DSSN’s and Widgets designed to help boost your partner’s success or give your customer some special advantage or gift.  Maybe the Widget is the gift and it also helps you build a DSSN around the recipients.

We’ll see a lot more on the Widget front as people work out how to employ them to create temporary DSSN’s around some initiative they want to drive.

Related Articles:

Social Media Today:  A Social Network for people who want to talk about Social Networks.

Posted in Marketing, saas, Web 2.0 | Leave a Comment »

With SaaS Are You Are 100% Helpless Or Much Better Off?

Posted by Bob Warfield on August 31, 2007

I can’t help but comment on some of the doings out there by John Dvorak and Matt Asay.  Troublemaker that he is (heck, I love John, he’s been stirring the pot ever since I can remember), Dvorak kicked the whole thing off with a rant about how maybe moving everyone’s software into the cloud is really not such a good idea.  It makes us more vulnerable and John tickles our sense of paranoia into a throbbing feelling of vague unease:

All this proves is that these Web-based applications cannot be trusted.

Matt makes the source of the paranoia seemingly much more concrete:

In a SaaS world, even more than in the traditional proprietary world, you are 100% helpless if something goes wrong. Not only do you not have the code (as you would if you had a on-premise desktop/server software), but you also don’t have the IT staff to be able to go in to troubleshoot. You’re completely reliant on the vendor.

I say seemingly, because both these guys are dead wrong.  There are some folks like Amy Wohl, Fryer’s Blog, and others chiming in with their two cents, but I wanted to give my own spin.

It may seem that SaaS leaves you helpless (I’m not even sure I agree with that), but reality is that you’re actually better off.  Let’s pick apart some of this stuff and get a real perspective on what’s going on. 

Let’s just start with the proposition about the code.  Who in the Enterprise has the code for their Oracle DB servers?  What about the code for SAP?  No takers?  And what happens when there is a big time problem with your On-premise ERP application?  Is your IT staff fixing it?  Or are you running to your ERP vendor to get them to do it?  Haven’t we reached a point where IT is writing very little code, and isn’t that a good thing because the code they do write is hopefully something to give their business a unique advantage?  And what about the issue that SaaS is largely a phenomenon of Small and Medium Businesses?  Aren’t these organizations even less likely to have IT staff writing code on apps that can be bought?

My experience building and selling mission critical enterprise software leads me to a much different conclusion than what the armchair quarterbacks are touting.  If your mission critical software goes down, you are not fooling around in IT with source code, you are on the line to Tech Support, and if it’s really bad, you are on the line to the Executives or CEO of your vendor and whatever VAR installed the silly thing demanding immediate action. 

Let’s walk through an unfolding IT crisis and see what happens with typical On-premise vs SaaS Enterprise Software.  I think you’ll be surprised if you haven’t thought about this or lived through the exercise yourself. 

I have to make a point in favor of SaaS right up front as we walk through the chronology.  If the SaaS vendor and their offering are up to snuff, they know you have a problem almost as soon as or even potentially before you do.  In fact SaaS vendors are much better positioned to have taken care of the problem before you will ever have a chance to see it than their On-premise cousins.  Huh?  Isn’t this just testing your code properly?  Why does a SaaS vendor have an advantage?  Testing is important, but SaaS vendors have another huge advantage over On-premise: they fix problems before you encounter them much more easily. 

I did some benchmarking among SaaS and Enterprise vendors by going out and talking to a number of my peers.  One of the questions I asked was quite illuminating: 

How many of the problems reported to your Tech Support organization had already been fixed in some release of your software?

I tended to get 2 strongly polarized responses.  The vendor either had no idea, or more interestingly, they concluded that well over 50% of problems were already fixed in some release of the software.  I can tell you that my experience was definitely in the “well over 50%” end, hence I wanted to see if others were seeing the same.  Since SaaS vendors are upgrading you constantly and transparently to the latest versions, 50% of all Tech Support incidents are being nipped in the bud before the customer even sees them.  Imagine what it does for customer satisfaction when half your Tech Support incidents are eliminated?  Bugs are going to slip through for any software, but with SaaS, we can fix the bug for everyone as soon as even one customer (or our internal testers) finds it.

While on the subject of testing, consider how much easier it is for the SaaS vendors to test because everyone runs the same version of the software.  Testers don’t have to split their time and energy among multiple platforms.  They don’t have to waste time certifying hot fixes that will only matter to one customer who stubbornly refuses to upgrade.  Worries about the interactions between patches and hot fixes are a thing of the past for a SaaS vendor. 

Continuing with the process, you’ve now gotten your ISV’s attention and its time to diagnose the problem.  Diagnosis is another area where the SaaS vendor has a huge advantage.  Before diagnosis can proceed, the ISV has to narrow the search down to one of three categories:

-  It’s a bug or product problem. 

-  It’s pilot error (the FAA is right, this is usually the reason).  But which pilot?  Was the software improperly customized or installed?  Are users asking the software to do something it just doesn’t do?  Documentation, help, or UI confusing customers (that’s only partially pilot error)? 

-  It’s an environmental problem.  I’ve had customer DBA’s delete all the indexes on my app’s DB and then someone calls and says, “The app has crashed.”  Well no, it didn’t crash, it just ran so slowly you wished it did.  Who deleted the bleepin’ indexes anyway?  In another case, a customer had a faulty router between 40 cpus of transaction processing and the DB.  Guess what that does for throughput, and why weren’t they on the same subnet anyway?

The customer (and the VARs, unfortunately) will always start out assuming there is a bug.  The ISV starts out assuming the problem is first pilot error, second an environmental problem, and only after eliminating the first two do they move on to the assumption there is a bug.  Diagnosis almost always takes longer than coming up with a fix, often days longer while your organization is in agony over the problem. 

Now let’s consider how the two vendor types (On-premise and SaaS) triage through the three diagnosis categories.  The On-Premise ISV will start out walking the customer over the phone through what’s happening, hoping to identify a misconception or user error right there.  We’ve all sat through these painful sessions where the Tech Support guy just doesn’t seem to get it: they can’t see your problem and it’s painful to explain over a phone.  Now let’s consider the SaaS vendor.  The software runs inside their data center, not yours.  This gives them the access to be able to see much more directly what you are doing on the application.  Clever vendors will set it up so they can see exactly what’s happening on your screen step-by-step.  Advantage SaaS.

If the phone session fails the next step is to check the bug database and see if anyone has reported anything similar.  But wait, the SaaS vendor can eliminate most of this as bugs get fixed as soon as they’re reported for all customers.  Meanwhile, the On-premise guys are going to tell you to install this new version or that patch.  Never mind that this can be a huge undertaking for Enterprise Software.  I’ve seen cases where just upgrading to a new app server version that’s known to fix the problem can’t be done because it would interfere with other 3rd party software running on the same server.  Drat!  We’ve also all been through doing the upgrade or reinstall on something and despite Tech’s assurances, it made no improvement whatsoever, it just wasted our time.

Are you beginning to see how this works?  No?  Let’s keep going.  The phone talk through didn’t help.  New versions and patches didn’t help.  Now we have to try to duplicate your problem on our in-house hardware as a final check against environmental issues.  The ease with which some DBA or person in the IT shop can mess up the carefully nurtured environment for a piece of software is frightening.  Database servers are filled with parameters and DBA’s like nothing better than fooling with them to get a little more performance.  Worse, some enterprise software just has to be constantly tweaked to keep it happy.  Of course with SaaS, your software is already running on our hardware.  The people that wrote the software have dictated the ideal environment.  You don’t have to wonder if you are the largest customer running on a particular stack that has hardly been tested.  Every customer runs the same software version on the optimal reference stack and that environment is tended to by experts.  Lastly, you are most likely part of a multi-tenant environment, meaning that if you are the only one with a problem, that’s another immediate tip-off that it isn’t environmental.  SaaS, move ahead three squares; On-premise, do not pass “Go”, do not collect $200.

Now we’re at the last, most finicky, and most contentious stage.  We know it isn’t environmental.  We know it isn’t a problem with a prior release.  We know it isn’t user error because we can see exactly what you are doing.  It has taken an On-premise vendor a huge effort and probably quite a bit of time to establish all this.  The SaaS vendor knows within the first phone call if they’re set up right, and already has a huge advantage.  Even better, they may have eliminated the problem before you encountered it.  But assuming that’s all failed, we now have to fix a bug.   

Even here the SaaS advantage is huge.  Customers for On-premise ISV’s frequently want the developers to fly out to their site to fix a problem.  It makes them feel better, because after the painful diagnosis process, they’ve now gotten the message up close and personal about how hard it is to do remote diagnosis.  Guess what?  With SaaS, the best and the brightest are already at your data center!  You get that red carpet treatment that is usually offered only rarely to the best and biggest customers no matter who you are when you buy SaaS.  And the developers are much happier and more productive.  You can never fly everyone to the customer, but all the developers are together for SaaS, and anyone who needs to help can easily jump in or give feedback.

Let’s consider a last issue in terms of preventative maintenance.  If you’ve been in the Enterprise Software game as I have, you will know that not all customers and SI partners follow your Best Practices recommendations.  Sometimes they can’t, sometimes they won’t, sometimes they just didn’t know, but always they should.  This can range from how the software is installed, the infrastructure supporting it, day to day operations, or whatever.  With SaaS, the vendor can ensure that the latest Best Practices are always used with their software.  Six Sigma devotees will recognize the enormous advantage SaaS has with respect to repeatability.  On-premise vendors will know firsthand of the tremendous variability of customer experience with the same software because of all the factors one has to get right before it all comes together.  With SaaS, the vendor is in control of many more of those factors, and this does lead inevitably to better Customer Satisfaction.

As to the “helpless” slant, the real power to help one’s self was never a matter of laying hands on software or hardware.  It has always been the ability to bring pressure on the vendor.  Once again, advantage SaaS.  The On-premise ISV has your software license check a long time ago.  At this stage they are gambling with maintenance and their reputation.  The stakes are higher with SaaS.  They get their payments monthly, and not all up front.  A monthly SaaS payment is bigger than a maintenance payment, aAnd by the way, most of the problems with these systems strike early on, so the SaaS vendor has a lot at risk from the beginning.  As Chris Cabrera at SaaS vendor Xactly is fond of saying, “We have to earn your business every day. “

I hope all of this makes it clear how much better off the customer is with SaaS.  It’s yet another testimony to what the final “S” for Service in the acronym really means (if you’ll pardon the double meaning): 

SaaS simply works better.

Related Articles:

Things that SaaS Customers No Longer Have to Worry About

SaaS Resolves the Software Prisoner’s Dilemma

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Posted in business, saas, strategy | 9 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 313 other followers

%d bloggers like this: