The idea of this article is to ask some questions and incite a discussion on certain issues in software as a service (SaaS), based on my technical experience.
Recently, I read an article about cloud computing on a prominent website which said that companies now increasingly prefer SaaS solutions in a “plug and play” mode. I believe the plug and play feature is the cornerstone of SaaS and could be one of the primary factors that can influence a customer while deciding on a SaaS functionality.
But how easy is this plug and play? Can a customer easily switch from one SaaS vendor to another if something goes wrong? This is especially in implementations that involve proprietary programming code that transforms the customers’ data into different formats for various purposes. A few examples of domains with such activities are B2B and analytics.
In a lot of electronic data interchange (EDI) B2B implementations the vendor could write tons of codes (in the form of entities called ‘maps’) that can transform the customer’s application data into globally accepted standards like ANSI X12, EDIFACT and TRADACOM.
In addition to this, there exist other codes which can work around the maps to pre-process or post-process the data. Implementation of a big client would normally take months and are done in phases depending on the size of the client. Now, if a client decides to unplug from a vendor for any reason then is it a financially feasible option to move? How can that move be made simpler?
Similar is the situation with various analytical tools. Most of them have a back-end application or a Perl/UNIX shell script which can transform the customer’s data according to the specifications given in the database. Some of these scripts are capable of doing very extensive processing of the data. Sometimes it could become extremely onerous to replicate such processing elsewhere if the structure of the raw data of the customer is complex.
This may not be a problem though, in SaaS implementations involving software that simply stores data, where there is no such ‘processing’ involved. In this case the client only needs to take the data and move. In such a case the movement and new implementation costs would remain minimal.
An example of such a non-processing SaaS implementation would be the database. Some of the analytical tools on cloud, like the retail price optimization software, involve minimal processing. And the client would only need the proprietary code if the new SaaS vendor cannot readily work with the existing data format of the client.
I am not into sales but, personally, if I own an organization, I would insist on some rules to be stated in the contract regarding the reuse of proprietary code. If there are such provisions in the contract, to be able to reuse any map or code that help in data transformation when we move to a new vendor or decide to do it in house, my company would be able to save substantial time on implementation, money and effort.
Currently cloud and SaaS are such strong buzzwords that it would almost seem like if you aren’t utilizing them, you aren’t keeping up. This could very easily cloud your decision making process and push you to a vendor who is not right for you.