BLOG: Zach Nelson, CEO, Netsuite

On-Demand Is No Pixie Dust

31 May 2006 - I am not the only person betting his company on the notion that companies inherently prefer to buy mission-critical business software as a service. But I believe some in the SaaS industry don't appreciate that our customers do not choose to buy their technology as a service because it is a service. Their decisions are made on the functionality of the product, not how the bits are delivered. In the disjointed mid-market where so many on-demand vendors do so well, it may seem like the real deal-winner is the delivery mechanism. But it is functionality, not channel, which sells customers - and more importantly to those of us who have built our business on this subscription model, keeps customers. People buy software to solve their business problems, not because it is trendy.

I believe there is a battle coming in the enterprise SaaS marketplace. It is the same battle that was fought five years ago over on-premise software for very large enterprises. Buyers will feel out their options and see that they boil down to two categories: point products vs. an integrated suite. I firmly believe this battle will have the same outcome now, in the on-demand mid-market, that it did then - the suite will be victorious, because only the suite can offer a reliable view of the complex transaction chain in a working enterprise.

That isn't the message you hear from the pundits who claim that miraculous "web services" free customers and developers from the difficulties of integration—that this magical cloud of middleware will make sure everything about the transaction matches up in the end. Make no mistake - I believe that web services can deliver powerful results by passing data between loosely coupled applications. For example, if you pass an address from the NetSuite customer record to Google, you get a map. That's certainly useful, but you'll notice it is simple only a one-way passing of information.

Most such web services integrations - called by the now au courant term "mash-up" - are based on this notion of data sharing. However, the excitement around mash-ups has led some to the conclusion that this approach can now enable composite transactional applications. And therein lies the rub. Transactions are not loosely coupled, they are tightly coupled. There is an enormous amount of data synchronization in the classic cycle of orders turning into invoices turning into deliveries and returns turning into reorders. That's the transaction cycle in a nutshell, and it is not something you can simply wash your hands off in a magical cloud of middleware. The clearest example of the difficulty of synchronizing data is the fact that the world's largest software company Microsoft can't make its mid-market CRM product synchronize in a meaningful fashion with its mid-market ERP product. If they can't do it with the source code and all their might, what chance does an IT organization have?

The big best-of-breed players and their top-tier consulting partners spent millions of dollars hoping to do just that in the last great war, and they lost. Ultimately, customers are compelled to centre their business operations around the transaction, and any solution which cannot accurately follow the transaction from A to Z and back again will lose, for the same reason SAP and Oracle won and Siebel didn't. When enterprise systems are not built around the transaction, they fail as enterprise systems. And when enterprise systems are not built around transactions, it becomes essentially impossible to synchronize invoices, returns and purchases.

The web services refrain is no different than the one best-of-breed providers tried to use five and ten years ago. Today the catchphrase is "Don't worry, it's all just web services; it will all be available and integrated." Then, it was "Don't worry, it's all just APIs; it will all be available and integrated." Just as nobody can argue that the loosely-coupled web services delivered today by the likes of Yahoo and Google aren't useful, nobody can say that open programming APIs are not useful. But as enterprise integration platforms go, both are woefully unprepared to deliver the complete view of the transaction throughout the organization in a consistent, unbreakable manner. At best, buyers will find out what the consulting firms found out about best-of-breed on-premise solutions years ago - that integration, if it can be achieved at all, comes at a price two to three times greater than simply buying a system which is built on the business transaction in the first place.

This may all seem scandalous coming from the CEO of an on-demand software company, but in my view it is just a matter of common sense and survival. Buyers want functionality, and care little about the underlying politics of how we deliver it to them. If a customer needs demand-based inventory replenishment, and you don't have it, it doesn't matter if your software is on-demand or hand-delivered from Mars—the customer won't buy it, because inventory replenishment is driving their pain. If your on-demand software can't address their inventory replenishment needs without breaking the integrity of their transaction process, you won't get on the shortlist - or, worse, you will saddle the customer with a point solution, leaving them praying for a magical cloud to solve their integration headaches. That's not sustainable in any delivery method.

Zach Nelson
CEO, Netsuite
www.netsuite.com

Please feel free to post comments and opinion below...

Related articles