Business & Technology Nexus

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.

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

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?

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?"

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. :)

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.

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.

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.

A tired Tim Minahan showed up in San Jose today for a continuation of his inaugural Procuri Supply Management tour. “It’s okay because the end is in sight” he said.

Tim delivered an excellent presentation on the value of Procurement executives in today's challenging times. He drew on historical trends, touched on high energy prices, and in general pumped up a receptive group of customers.

Before the event, I asked about Procuri's take on SAP’s Frictionless acquisition. “Will we see them in some deals and lose one or two? Sure. Would we have rather had them go under? No doubt. But we’ll do fine,” said Procuri's RVP of West Coast sales. My own view is the same – it’s not clear to me it will slow Procuri's momentum.

Sun gave a good presentation on their achievements in the Sourcing domain. And a division of Sony talked about their central contract management success story.

All in all, as an outsider, I'd give Procuri an "A" on a nice event. It was well-staffed and the tone seemed the right balance between professional and casual.

Good luck in Irvine tomorrow Tim!

Debbie Wilson did a great research piece for Cool Tools for Purchasing on eProcurement catalog usage trends. It reinforces a belief I've long held that over-engineering catalog implementations (and the software that supports them) can be deadly. It's a must read if you have or are planning an eProcurement implementation. Flat files are dead! Long live flat files!

Although I can't quite figure out whether cXML.org is truly independent or just an Ariba "satellite state", they do have some good documentation on their website on the Ariba-sponsored and largely Ariba-specific cXML business documents.

One of the most widely used areas of the cXML "standard" is supplier punch-out. For those few un-initiated, supplier punch-out is a mechanism that allows procurement systems to direct employees to supplier websites to shop for (& configure) items while still retaining context & knowledge of the buying system. After shopping & configuring, employees "check-out" through their regular procurement system.

cXML is a handy standard for suppliers, given that Oracle also supports it. Plus there are a good number of supplier helper applications offering built-in support. So a supplier can be sure that investing in support of cXML for punchout will pay off – buyers will use it!

There are 3 central documents in the cXML punchout framework:

PunchOutSetupRequest – from buyer to supplier as the employee "punches in" to the supplier website to shop

PunchOutSetupResponse – from supplier to buyer acknowledging request & returning webstore URL for employee to shop at

PunchOutOrderMessage – from supplier to buyer concluding shopping experience and returning items selected for purchase

The messages are unique, but here are some of the elements you'll find within them:

1) From, To, and "Sender" sections identifying the parties involved

2) URL's for systems communications between buyer and supplier

3) Ship-to information

(This is a strange part of the protocol, where Ariba cXML.org wants to make it easy for suppliers to treat the punchout as an online order & match the eventual PO back to a shopping cart they saved. It's dangerous to use this though, as ship-to addresses are not final until the buying organization cuts the PO. So my advice to most suppliers is to ignore this info. Not only could you wind up computing the taxes incorrectly, you could also send the order to the wrong place!)

4) Items to be purchased

An interesting aspect of the cXML punchout is security. Unfortunately, there are "options" which is a terrible, terrible thing for a standard to have. Why terrible? Because it means a buyer can't just say "do you support cXML punchout?" – instead there has to be a detailed conversation of how they support it.

The simplest security mechanism is a "SharedSecret," essentially a password sent in clear text that the supplier can recognize. Other methods are using a MAC code (completely worthless and complicated, don't bother), and using server digital certificates.

Now initially, and even in the documentation today, cXML.org recommends "SharedSecret" be used only when directing punchout via the Ariba supplier network. In this way, the network becomes the trusted agent, and will faithfully intercept a buyer's secret and parse it out of the XML, replace it with the supplier's secret, and forward it on. Neither buyer nor supplier need to know each other's secret. Now that's handy!

But handy comes with a price – suppliers and buyers are locked-in to the Ariba supplier network, which now charges! The lock-in earns Ariba a critical stream of information on buying patterns they could later use for benchmarking.

The trouble is the network adds no value and at the same time inserts a single point of failure! Not good. Real-time punchout is far different & more difficult from an operational standpoint than the other documents the network handles, such as PO's and Invoices.

So avoid using an intermediary for punchout if at all possible!

It would be interesting to find out how many buyers and suppliers are ignoring cXML.org's advice and are circumventing the network while still using the SharedSecret for authentication. I believe it's the primary use case even though it's nowhere near secure.

Server digital certificates seem like the eventual winner for "direct" punchout, but until recently they have cost real money to acquire. Verisign and others charge between $1000 and $2500 for a certificate (you ridiculously expensive incumbent vendors ought to be ashamed of yourselves as the provisioning of a certificate and its maintenance are TRIVIAL). But luckily, emerging services such as CACert.org are driving the cost to 0 & in my view should quickly force the incumbents to adapt or die. But until news of the new services drives down costs, not every supplier will be quick to spend a few grand a year to support a buyer convenience.

Now, for detailed step-by-step instructions on supporting cXML, check out this pdf on cXML.org.

Have your own thoughts about cXML punchout & experiences you're willing to share? Send 'em my way!