Tasos Christidis

In the organization’s journey from an on-premise Business Application setup to a Software as a Service one, one of the key factors of success is data migration . Of course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution for my case?”, “Does it address my special requirements?”, “am I content with the reporting/BI capabilities that it offers?” etc. But having answered all of the above, you should take into consideration the data migration issue. This post will point out some very significant issues around this subject, which you need to address and examine; probably in close co-operation with the SaaS vendor of your choice, before accepting their financial proposal and start the journey.

ITSM (“Information Technology Service Management”) is generally defined as the shift from managing the technology stack inside an I.T. Department (or in the enterprise, in general) to addressing real-life business issues that generally come down to Customer Service. In other words, according to ITSM methodologies, I.T. must no longer focus on managing the technology; instead it must set its goals towards aligning with the rest of the business and be an equal player in the effort (design, contribute) towards generating value-added services both for the business users and directly for the customers.

The advantages of the cloud and specifically Software as a Service (SaaS) are very well known. Everybody’s talking about them all over the net, at forums and in the pre-sales calls of the cloud companies. People are talking about financial benefits that SaaS brings in their P&L, several cost saving factors, security, portability and access etc. One more advantage that is less frequently discussed is this of the agility that SaaS brings in the entire I.T. function, structure and governance. In this post I’d like to focus on this exact point, thinking that maybe it is usually understated.

The relationships between customers and providers in the cloud business are generally governed by the Service Level Agreement or SLA. In a previous post I made the point that a really “tough” SLA is probably not the “holy grail” of the cloud business, which every customer should be looking for. In this post I will continue the same line of thought, focusing this time in the impact that a strict SLA has on the customer organization itself. For this purpose, I will use the term “Reverse SLA”.

The cloud business brings some very interesting and unique characteristics in the way customers and vendors are engaging: For the first time in computer history massive amounts of data are processed and stored outside the physical boundaries of the enterprise (its LAN or WAN). Also, vendor companies can reside thousand miles away from the customer premises and they are run by people that most probably the customer will never meet in person or maybe even talk on the phone. These unique characteristics make the customer/vendor relationship very interesting and also somewhat difficult to describe. Such relations are typically governed by the Service Level Agreement (SLA) which the customer signs or in some cases just “accepts” with the click of a button on the web page of the cloud service they’re subscribing to.

As anything sold, quality is the first and most important factor for its success on the market (price is the second most important thing, but we will not deal with it, in this post). During my engagement with the Software as a Service business I have found out that Quality is an issue that needs to be redefined in that context. I started thinking about this, driven by the fact that “traditional” software “virtues” are not enough to build a sustainable SaaS income. By the term “traditional” I mean all the usual quality elements or performance indicators that the buyer expects from any kind of software (SaaS or not-SaaS): To be error-free To be fast and reliable To be user-friendly To be adequately supported by its vendor To provide insight to the data that it keeps (and not just to… keep them)