Business & Technology Nexus

Dave Stephens on technology and business trends

Archive for May 2006

Sass on SaaS – Noah Eisner Responds

with one comment

My colleague Noah Eisner sent me interesting commentary on SaaS. Here it is:

saw your post on SaaS vs. on-premise. also i read minahan’s diatribe. i think the confusing issue is separating the solution from the SaaS part. as an example, back when i bought a prius, i saw a bunch of people who said that buying a hybrid car doesn’t make sense financially. they said that you just didn’t make your money back in savings…however, these reports always made one key critical mistake. you can’t just compare a prius to another non-hybrid car. two cars are totally different in their look, feel, capabilities, etc. the only way to make the argument if buying a hybrid pays is if the same car is offered in a hybrid and a non-hybrid option.

the same thing goes for software. as much as people will say that salesforce automation software is commoditized (which is crap), people still do evaluate the features/capabilities and pick the solution that is best for their business. so, when it comes to evaluating the TCO of salesforce.com vs. Siebel on-premise, it is impossible. the closest actually SaaS vs. on-premise where the pricing is available is SugarCRM. for them, SugarCRM enterprise is $885 annually per user for on-demand and $449 annually for on-premise. both options include unlimited online and email support. so you pay $436 per user annually for the on-demand hosting. now, sugar’s on-demand is a dedicated application/database per customer, not the same as SaaS pure multi-tenant.. but the costs are probably not far off.

so, is $436 per user per year a good deal…maybe? it depends…maybe if you don’t have too many users. but at some point, it may become expensive. also, over time, does the cost for you to host it go down…do you become more efficient…and thus does the TCO change over time?

as far as minahan’s stuff

– true multi-tenancy doesn’t matter unless it fundamentally allows you to do things quicker and cheaper as a software provider and then pass the benefits onto your customers
– can you maintain quick delivery cycles in on-premise models? probably yes. the problem isn’t so much old versions in the install base but that the software grows in complexity…which is the same problem that a salesforce.com will hit in the next couple years. the rate of their compelling new features has certainly slowed from its earlier days…especially if you factor in that they have had a ton more developers on the product recently.

Written by Dave Stephens

05/31/06 3:15 PM at 3:15 pm

Posted in Opinion

Sass on SaaS – Iasta’s David Bush Responds

leave a comment »

Thanks to David Bush of Iasta for the following thoughtful commentary on the SaaS questions I posed in my previous post. (Iasta has a great esourcing forum that I recommend highly for Sourcing professionals.) Here's his SaaS response, unfiltered:

Hi Dave, I wanted to take a minute to respond to your blog yesterday with some comments, feel free to post… As full disclosure, we offer both SaaS and Behind the Firewall. The huge majority choose ASP…

1) Why is multi-tenancy a good thing for customers?

Economies of scale. If a SaaS provider can apply hardware and a single software instance across multiple clients, their operational costs go down, and they can lower the fees they charge. This is a classic argument of spreading the costs around to multiple parties instead of custom writing code for everyone.

2) What contractual obligation do vendors offer to furnish your data if you decide you're ready to exit the rental market? Said more simply: what will it cost to leave the party?

Each user of this technology platform should review the contract to confirm that they own the data…but they should own it! In addition, it would make sense during a demonstration that exportation features exist and are easy to use. Iasta clients can dump the data at any time and we have always given people time beyond contracted periods to remove. There is never a fee from us for this and the only thing we would consider charging for – would be to contract for the exportation and reporting. We have done this before and not charged at all, but then again, we are smaller and have better service than any one else :). Typically, there should be no need to contract this process for a fee.

3) Will SaaS vendors offer a written SLA with financial penalties if service is interrupted?

When you consider that third party installations are no different then in-house installations in that they can be brought down by any number of forces beyond their control which include, but are not limited to, extended power failures, natural disasters, and Internet failures and that your in-house software could crash at any time when you use a new feature for the first time, everyone is in the same neighborhood.

When you consider that a mature on-demand provider will write and deploy code with the same quality as a traditional software provider, is this really an issue? Furthermore, a SaaS provider can respond more quickly to system problems, should they arise, than a traditional provider who may have to first send someone to your site. On the rare occurrence of a bug report, we have them fixed within a few hours at a maximum.

Personally, I would be more concerned with insuring the maturity of the service provider and the hosted infrastructure than I would with trying to wrangle an SLA. If the service provider has UPS systems, multiple Internet providers, and hot-swappable fail-over servers ready to go, chances are your uptime will be much greater than if you hosted the solution in house.

That being said…Iasta has an embedded SLA in our all of our contracts that is good enough that it does not get red lined. And yes, it does offer financial compensation back to the client. Our uptime rate is well north of 99.9%, so an SLA is usually immaterial.

4) How many SaaS vendors are too many SaaS vendors for an enterprise?

I would say that depends on the quality of the SaaS offerings and whether or not they overlap. If each SaaS system serves a distinct function and provides a standard API or standards-based data import/export facility (such as EDI, or, preferably, XML), then there should be no problem utilizing each offering to the full extent possible without conflict since you will be able to import the necessary data into your internal ERP and financial systems as necessary.

I tend to think that Capitalism also will play a hand in this. If the model sucks and the software sucks, the company will pay the ultimate price.

5) Where are the value-added services?

Most SaaS solutions offer free upgrades within the lifetime of the contract – most traditional software providers do not. That alone adds value. In addition, many SaaS providers offer continually updated and expanded free-online documentation, training, best-practices guidelines, and even (user) forums where as most traditional providers give you a manual at the time of purchase and that’s it.

There are also many services available (again, on-demand) for modest fees that you would pay consulting firms 3x for virtually the same thing. Roll-out plans, category management, global supplier support and staff augmentation are all services that we regularly provide, upon request.

6) Is there any non-vendor-sponsored data comparing TCO of on-premise vs. on-demand?

Good question. Considering ASP/On-Demand/SaaS has been analyzed by groups such as the ITAA and IDC, who are known for being impartial, I’m inclined to believe that most of the stats are true.

-David Bush

Written by Dave Stephens

05/31/06 3:02 PM at 3:02 pm

Posted in Opinion

Sass on SaaS – More Questions

with 2 comments

I'd love to hear people's thoughts on these questions:

1) Why is multi-tenancy a good thing for customers?

Consider this excerpt of a salesforce.com email alert after multiple severe outages of their massive single instance:

"As part of our efforts to optimize the salesforce.com service architecture by separating our NA1 service instance into four new instances, NA1, NA2, NA3, and NA4, we are now preparing to migrate your Salesforce.com organization (EAI, id: XXXXXXXXX) to the new NAX instance."

2) What contractual obligation do vendors offer to furnish your data if you decide you're ready to exit the rental market? Said more simply: what will it cost to leave the party?

3) Will SaaS vendors offer a written SLA with financial penalties if service is interrupted?

(In fairness, this was a huge issue with Oracle customers & in my time at Oracle we never offered it. And for good reason.)

4) How many SaaS vendors are too many SaaS vendors for an enterprise?

Because for most companies there is still integration work, no matter whose computer is running the application. So is SaaS just for spots where companies want to ride the "bleeding edge" of functionality in niche areas & then eventually consolidate them back?

5) Where are the value-added services?

Surely there has to be more than "templates" out their for captive tenants. (Ariba may be the most progressive here.)

6) Is there any non-vendor-sponsored data comparing TCO of on-premise vs. on-demand?

Written by Dave Stephens

05/30/06 9:15 PM at 9:15 pm

Posted in Opinion

The Other Side Of On-Demand & SaaS

with 2 comments

It's been my experience that enterprise customers are trying to balance 3 factors when purchasing software: control, cost, and speed. After seeing all the SaaS "mania" going on lately I thought I would go ahead and offer yet another opinion on the subject. And it's not completely favorable. But first a short history.

In 2000 my team developed Oracle Exchange, Oracle's first multi-tenant hosted service. We chose to issue it SaaS, though eventually we relented to customer pressure and issued the software more traditionally too. Although my principal role was building the software, I also managed a fair amount of Oracle's online delivery, including software upgrades. Going SaaS enabled us to issue releases every quarter. Going SaaS enabled our customers to go live in just a few weeks after signing deals.

So why did customers eventually want to take control of the software themselves? Over time, their thinking evolved. They had figured out what they wanted from the platform & were either satisfied enough with the feature-set -or- looking to heavily customize the solution to meet their needs. It was a natural maturation in their viewpoint.

It makes sense, doesn't it? As an enterprise's experience with the software evolves they understand what they truly need. And once they get what they need they want to "freeze" the solution & avoid incurring any more cost. Sure, 5 years down the road the whole thing might be open for re-evaluation. But at the current time, and for a long time to come, they're done.

You see, SaaS is great when you start. It's a year or two in when you may start to sense you've painted your company into a pretty tight corner. So customers need to go in with their eyes open, and separate their short-term "get a quick win" thinking from their long-term plans.

Don't get me wrong, there's a lot that's right with SaaS. For Procurement, SaaS is what makes a best-of-breed selection possible at many firms. Procurement just doesn't carry a big enough stick to garner IT resources – IT instead tend to be focused instead on fixing past mistakes in a horribly complex internal infrastructure. SaaS can be the perfect end-around on a reluctant & overwhelmed IT organization.

Further, you get "live" on solutions faster the SaaS way (when you don't have to install and implement them). SaaS is perfect for getting up and running fast. All the normal & necessary red tape, from security audits, to hardware selection, etc, has all been done for you. It's as close to plug-and-play as enterprise applications will get.

These conveniences are compelling, no doubt about it. But SaaS comes with a cost. And that cost can be summed up as "loss of control."

With SaaS, best-of-breed vendors can be "sloppier" in their product development, and can issue patches constantly to fix problems that traditional software delivery would have never allowed. As a customer, you may or may not get to test new versions of the software before they are forced on you.

Here's what's behind this behavior: Software producers HATE maintaining old versions of their software. Customers would be surprised how much tension and angst and, above all, thought goes into how to make older versions of enterprise applications "go away".

For large firms like Oracle and SAP, old versions can be maintained with very high profit margins. They are juicy – just the type of revenue stream & profits that gets these businesses extending their release cycles to 2 or 3 years or beyond. The playbook is simple: outsource all maintenance to India, encourage customers not to touch their instances AT ALL, and receive big checks in the mail.

But for smaller software vendors trying to tap into the latest trends & become the next big thing, older versions kill. The name of the game is to keep all your customers at the highest rev, thereby reducing support costs and improving margins!

The small guys need their customers to upgrade at the their pace & discretion (with some sense of reasonableness of course).

And no doubt this "forced march of upgrades" is initially warmly received by customers hungry to get complete functionality. But very soon thereafter it is dreaded. And for good reason. Change causes instability – if a customer already has what they need their best course of action is to keep it as-is (If it ain't broke don't fix it). And customers usually don't understand that forced upgrades don't just apply to software. They include your hosted operating system, network switches, routers, and the hardware itself.

When I was at Oracle and thinking of how to respond creatively to multi-tenant SaaS, I thought through a ton of analogies. The one I liked the best were 2 pictures – one of rundown apartment buildings (for SaaS) and another of a model home (for software you buy a perpetual license to).

the caption, of course, was "tired of renting your software?"

Tired of renting your software? Own your own home!
And in the end that's just what SaaS is – a large, shared apartment building where you rent… your software.

The other curiosity I have with SaaS and the whole software rental business model is the "landlord." You see, because of time to market pressures, SaaS and the software provider are synonymous. But in a mature version of the current market, I predict the software provider and the SaaS provider (aka hosting provider) may very well split into separate entities.

Perhaps that is a contrarian view in today's SaaS times. But there's a reason GoDaddy.com charges $3.99 a month for an online hosted instance – including a full development infrastructure, database, etc. They are better at it than salesforce.com or any other high tech start-up out there. And they can certainly beat the pants off Oracle or SAP.

So isn't it possible the a mature market around SaaS will look a whole lot more like traditional outsourcing of IT systems management? I think so.
But perhaps until then this post will just be sass on SaaS. :)

Written by Dave Stephens

05/26/06 3:18 PM at 3:18 pm

Posted in Opinion

Gene Richter Remix

leave a comment »

For those looking for a little light weekend reading, here are 2 articles the "Yoda of Procurement" published on Purchasing.com.

Containing Total Spend, 11/6/2003
http://www.purchasing.com/article/CA337312.html

Centralize!, 2/6/2003
http://www.purchasing.com/article/CA273586.html

Note also that the Richter Foundation has issued their 2006 scholarships to six supply chain students.

Written by Dave Stephens

05/26/06 10:35 AM at 10:35 am

Posted in Opinion

cXML.org Just An Ariba Facade

leave a comment »

A reader duly followed up on my question around cXML.org’s “independence” from Ariba – and I thought his comment was worth posting:

CXML.org has some hints as to who owns it. Judge for yourself how ambiguous it is.

cXML.FAQ #10 and #11 (http://www.cxml.org/prnews/faq.cfm)
“Ariba … retains control over the standard.”
“cXML.org is not open to membership requests.”

And if that’s not clear enough, check out the License Agreement, item #9 (http://www.cxml.org/license.cfm)
“Ariba, Inc. shall be deemed the Licensor.”

So it sure would seem cXML.org is really just a disguised Ariba website. In fact, had I been smarter I would have looked at who owns & pays for the cXML.org domain. Yep, you guessed it: Ariba. But even so cXML remains one of the most widely used formats for buyer & supplier communication around. And that can’t be all bad.

Written by Dave Stephens

05/24/06 2:19 PM at 2:19 pm

Posted in Opinion

Rationalizing Consulting “Overflow” Supply

leave a comment »

A few large firms with big consulting practices seem to be operating off the same playbook lately – dramatically trimming their supply base for "overflow" consulting work.

You see, consulting firms of any reasonable size often can't staff all the work they receive themselves. So they outsource the "overflow" to trusted partners who can ensure high quality. And if they can markup their rates & turn a profit on the outsourcing, so much the better.

But I've been wondering about the rapid rationalization the large firms are pursuing. In general, the trend has been from small, local shops who may have personal relationships with both the customer & the large firm to larger, amorphous organizations able to operate across locales and regions.

No doubt the rationalization is resulting in great savings & improved profits on outsourced consulting work. But time will tell whether customer satisfaction ratings can be maintained through this transition.

But without more hard data, rationalization of your consulting "overflow" supply base has to be considered a best practice. And with savings being reported between 10 and 30%, it may be just the place to look to meet your next spend reduction target.

Written by Dave Stephens

05/24/06 8:19 AM at 8:19 am

Posted in Opinion