FUD Hits With a Thud

The tempest in a teapot created when David Keene of Digital Signage Magazine attempted to “sort out” digital signage software architecture with some generalizations about the premise-based versus SaaS approaches has resurfaced. Mr. Keene has published an article in the July/August issue of DSM on the topic, with follow-up articles by guest contributors from both camps. Leading off was Jeff Collard, President of Omnivex, representing the premise-based crowd. Before diving into Mr. Collard’s statements and apparent motives, let me state unequivocally that there is no silver bullet: SaaS is not always the answer, and neither is premise-based. Our own approach underscores that belief. We are fundamentally a SaaS provider, and currently derive 100% of our software revenue from that model. That being said, we have no less than three enterprise (e.g. premise-based) proposals in various parts of the sales cycle, and we anticipate more. I’ll circle back to why shortly.

Mr. Collard begins his article with similar disclosures and assurances that one size does not fit all. Then he dives into his case for premise-based software by comparing SaaS to riding a bus, and premise-based to owning a car. It seems that the bus is fine for city-dwellers who have a defined need, but the family BMW is where it is at for those in control of their own lives. Ignoring the subtle implication of class distinctions, his argument that premise-based software provides more flexibility and control than SaaS (“a general solution that caters to a broad base of requirements”) just doesn’t hold water. Here’s some enlightening facts: core digital signage requirements do not vary widely. One must manage and distribute content, playlists and campaigns; manage media players and locations; gather and manage data and develop reports; manage central and local users; and allow for significant scaling, among other things. If someone desires functionality that is unique to a specific environment (say a hotel), that alone does not make them a lock for a premise-based solution. The ability to adapt a software solution is not unique to premise-based software. A SaaS provider would want to use an approach that can be generalized to multiple use cases, and therefore more valuable to a wide variety of customers. That requires a higher level of abstraction of the requirement, and perhaps more thought in the design process. It also maintains the concept of single image, multi-tenancy that is core to SaaS. A premise-based provider can also modify their software, but that tends to drive them down one of two paths. The first is multiple versions of their software deployed in the field that require maintenance and can make enhancement of the core product more difficult and costly. The second is the creation of a series of point solutions (e.g. the “hotel” version, the “cellular store” version, etc.), which drives the product into niches and narrows its appeal. Not that there is anything wrong with that, as George Costanza would say.

Collard’s next argument is even more specious. He says, “If all you want to do is greet visitors in your reception area or entertain them while they wait, SaaS might be the right model for you. If you want to motivate your staff with their performance against targets or indicate what meeting is in what room based on your meeting room scheduling software, then a premise-based product would be a much better solution, because it can tap into other databases… to create targeted messaging.” Suffice it to say that staff motivation and presentation of data from other systems and sources is not unique to premise-based software. I am sure Omnivex spent a lot of time interfacing with hotel scheduling software to meet customer requirements. But their success in doing so was based upon their development skills, and was not in any way tied to their premise-based approach, and to assert that it was is disingenuous at best.

Apparently anticipating that particular daylight test, he goes on to head off this argument by invoking fear, uncertainty and doubt (a/k/a FUD). He contends that sharing business data with an external system, such as a SaaS server, is a scary security threat. He claims that “you never know where (your data) is located or who has access to it,” and that “you don’t know what country it is in or if it is being backed up somewhere else.” Time out, Jeff. Let me lead a parade of SaaS vendors who will disclose the scary secret of where their servers are, and invite others to chime in. Our primary server is in Tampa, Florida, in a highly secure, state-of-the-art facility managed by Peak 10. Our failover and backup site is in Peak 10’s Charlotte, NC site. In the unlikely event of secession of either state, we could easily relocate to any number of Peak 10 facilities. Customers and contracts determine who has access to their network data, and we consider the fact that each network’s data is backed up daily to be a service, not a threat. I wonder how many of the tens of thousands of Salesforce.com SaaS customers stay up at night worrying about who has access to their sales pipeline. I am pretty sure that is more valuable business data than the fact that the Rotary Club will be meeting in Skyline Room B next Tuesday.

Selling through FUD is the tool of those with little else in the toolbox. Collard’s FUD techniques continue with the classic “what if” scenario used so well by FUD subscribers. He wonders whether if you are silly enough to trust a SaaS vendor with business data, then what would you do if that company was “sold to someone less scrupulous”? Come on. I feel like Dan Aykroyd in SNL’s old Point Counterpoint bits.

Collard states the fact that SaaS customers rely upon their vendors to “provide adequate bandwidth, uptime and security”. Yes, they sure do. They also rely on their SaaS vendor to provide infrastructure and services that provide ROI when measured against an internally-based solution. When he implies that browser-based access is slow and sub-optimal he thumbs his nose at modern software architecture, web-based computing, and the internet itself. He knows very well that even an interruption in internet access will not send a properly designed SaaS-connected media player into darkness. But it serves his purpose to imply it would.

He stays with the FUD tactics by implying that the demise of a SaaS vendor would hobble a customer, whereas the demise of a premise-based vendor would not. Most SaaS agreements are (or can be) backed up by an escrow agreement that would release code in the draconian scenario. Proper diligence in the selection process would normally prevent the selection of an insolvent vendor in the first place. Do Mr. Collard’s customers sleep well knowing that their company’s goals are not tied to the success of Omnivex? If so, I would assert that would make them just another vendor, and not a trusted business partner.

I mentioned above that we have seen the need to make proposals for enterprise (premise-based) licenses of our software. These situations were not reactions to customers’ security issues, viability concerns, or worries about browser speed. They were generally the result of scale. When a SaaS-based network grows to a certain size, the monthly subscription fees will eventually reach a level where an analysis of self-hosting vs. external hosting is in order. We consider that scenario to be a telltale sign of success of the customer network.

SaaS vendors and their customers by definition have a stake in mutual success. The evolution from a SaaS model to an enterprise model is a natural result of growth and mutual success. A premise-based deal as described by Mr. Collard sounds a lot more like a one-off deal than a long term relationship. It would have been more interesting to read arguments based upon Return on Investment, speed to deployment, the merits and tradeoffs of single image/multi-tenancy, the scalability of location-based software, and the case for and advantages/disadvantages of user-driven enhancements in each model. Unfortunately, the arguments presented for premise-based software were based on subliminal and direct attempts to position SaaS as less secure and SaaS vendors as less viable. It is clear that the marketplace does not buy into those arguments. FUD is so 20th century.