Tuesday, November 12, 2013
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”.
Although Reverse SLA is not a widely used term, I would define it like this: the mirror in which all vendor commitments are reflected and produce an image of the customer’s obligations in terms of response and organization, in order to smoothly receive any service that is provisioned by the SLA.
In this post I shall not analyze what the usual KPI’s are (lots of documentation for this on the net) but I intend to give some examples of some customer-side issues or challenges, which may prevent the smooth execution of an SLA. I will list the most frequent customer requirements and explain the implication that these requirements may have on that same customer’s organization. If you are thinking about using cloud services, when you are done reading this post you will hopefully have reached a good level of understanding about the impact that cloud adoption will have on your organization. You will also have understood that cloud services are not only about vendor meeting a series of obligations but also about your own part and role in the whole process.
A. Service availability and hours
The SLA includes the working hours that the service is available (typically, lots of “nines”) but also the time frame that the provider can/should serve customer requests. Focusing on the latter, this frame may vary depending on criticality (bugs, change requests, etc.). This issue sometimes becomes very important when the customer does not operate in usual office hours but spans beyond the normal hours of the vendor.
In that context, it is only about the vendor having the proper mechanism in place to process such requests but also about the customer having to be prepared to get feedback and finally assist the vendor in resolving the issue. Here are some examples that may prove problematic on the customer side:
· In each case of issue or problem there has to be a departmental or overall representative (or manager) to be contacted by the vendor and in general be the communication hub between the two parties. If the service spans beyond normal hours then the customer has to nominate a person who will be available during all that time span.
· Also, it must be clear that this designated person should be engaged in all circumstances and that it is not normal for end users to directly call the support center, trying to resolve the issue through non-authorized channels or procedures. In such cases, the vendor may refuse or declare inability to respond.
· If the issue requires some user action, then a contact person must be included in the request. Otherwise, this may result to a resolved issue that the customer’s organization will not able to digest (e.g. test a new patch etc.)
· Provide sufficient access to the vendor mechanics to look at the issue and go as far and as deep as they need to (without compromising in-house security, of course)
B. Service throughput
It is not only a matter of whether the vendor can deliver. It is also a matter of “how much” can they deliver in the unit of time. Some customers may have increased demand on this “service throughput”. But what is the customer doing to ensure that all this throughput is absorbed by its organization, as fast as it is delivered? For example:
· There must be adequate resources on the customer side to perform User Acceptance Tests and the infrastructure to schedule, agree and monitor delivery schedules. This, among other cases in this post, is a good example of why the customer can’t do without a designated I.T. department or – at least – person in its organization.
· In special cases where the throughput or availability needs to be higher than usual, the vendor must be informed beforehand in order to be given time to organize and be prepared for that special occasion. But the same applies to the customer’s internal organization.
C. Response times
The response times may vary depending on type of request. For example for bug-type of requests the response may be just a few hours and for Change Requests it could be days. Many times customers are pushing very hard to minimize all these times/metrics. But they must be able to respond to the issues as fast as they are asking the vendor to. There is no meaning in having the vendor respond “fast” when you don’t have the structure in place to receive the outcome of this task. Otherwise, you run the risk of:
· Receiving extra charges for extra-hours service that you received without really needing it.
· A problematic case that was resolved fast enough but you weren’t “there” to accept it.
· A bug that was declared solved but you didn’t re-test and accept it in your Production Environment (with potentially disastrous effects)
D. Escalation procedures
It is probable that not all issues are resolved through the “service desk”. They may require escalation to higher authority, some management decision etc. Customers are right to ask from vendors to define such procedures. But they also need to have similar processes (and people) in place in their organization, too. Otherwise, the escalation process will not work and will most probably end up in a “vicious cycle” of “who’s to blame?”
E. Security guidelines
This is a very well-known issue that customers are pushing vendors to perform. And they are right! But what are they doing in order to meet the same standards that they are asking from the vendor and – if what they’re doing is not enough – then who’s to blame in case of problem? A few examples:
· Are the customer’s Personal Computers equipped with up-to-date antivirus programs that ensure proper function? If not, then is the Service Desk responsible to remotely resolve a communication issue between the client and the server?
· Is the operating system and patches installed according to the vendor initial or current requirements? Otherwise the vendor cannot be held responsible for the user’s PC not performing correctly.
· Is the customer using the designated and tested/recommended web browsers that the vendor product supports?
I’m making the case that it is not just a matter of provider capability to “deliver” but also a matter of the customer meeting the requirements that automatically arise by the provider’s actions to “deliver” and its ability to digest the input that is created from the execution of the SLA. Also, it is now evident that abiding by the SLA requires that adequate staffing and expertise are in place, on behalf of the customer, otherwise the provider can’t be expected to “perform” above the level that the customer can “absorb”. In other words, it is probable that tough negotiation results in an SLA that can’t be monitored by the customer and, as such, has no real meaning or benefit for the customer.
Monday, October 21, 2013
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.
Many times there is no option to “discuss” or “negotiate” such a document the way an “end-user license agreement” was negotiated in the past, when a piece of software was “sold”. Customer may or may not accept the terms (and move on to the next available choice). This very fact builds pressure on customers to accept a document that perhaps it does not find them exactly in accordance and also to vendors to come up with a collection of technical and legal terms that are “safe” for them but also not “intimidating” for the customers: something that can persuade customers to get on board the service instead of driving them away. These two “opposite forces” tend to reach some kind of equilibrium and this post investigates what this equilibrium point is.
One way to describe the customer/vendor relationship is to have a very detailed SLA, defining all possible outages or out-of-service conditions and that’s what many customers are looking for. But I would argue that the more detailed an SLA is, the more safe it may become for the vendor, leaving the customer uncovered (or, better, inadequately covered) in some cases. How can this be? Here is an example: The customer asks for specific provisions when there is data loss in the cloud service. This raises the question of what will the vendor’s obligation be for damage caused by such data loss? Obviously, it can’t be a number many times larger than the yearly fee that the vendor collects, otherwise the vendor has built a high-risk business, which makes no sense. And then, it can’t be a number too low, otherwise the customer doesn’t have adequate insurance for their data. In the hypothetical case where the SLA does not provide anything for this case, then the customer might ask for astronomical figures making the case that the data loss has seriously damaged its business. The vendor, on the other hand, could argue that they owe nothing to the customer, since the SLA did not include any specific clauses. A real mess in the customer/vendor relationship, I’m sure, and a real deal-breaker. But what is the mitigation for such risks? Perhaps a very detailed SLA that includes specific provisions for each distinct case? I wouldn’t agree that fast! You see, analyzing every little detail will work not only for the customer’s benefit but also for the vendor’s. The vendor might use these clauses to limit their risks to an absolute minimum. So, it is probable that in the above example of data loss, the vendor is obliged to offer some discount or re-imbursement on the next invoicing period and they are “off the hook”, that easy.
The point here is the following: A very detailed SLA covering all possible cases of risk, quantifying each and every small detail is not the “holy grail” of customer/vendor relationship that all customers should seek. Instead, customers should also look for other ways to make sure that their selection of vendor is correct, like investigating the “word of mouth”, asking for real-life references, and in general performing due diligence on the vendor selection process.
Saturday, October 5, 2013
One of the many advantages of web applications (Software as a Service – SaaS applications are the best example here) is their “portability”. Before the rise of business web applications one had to tap in a corporate server using difficult to understand or use technologies like “remote desktop” etc., to gain access to corporate data and functionality. Then the World Wide Web came and new, reliable and safe (although many don’t believe so) applications saw the light of day. Tapping into the corporate environment became so much easier. Also, using a computer other than one’s own became possible (e.g. internet café, a friend’s house, borrowed during vacation etc.)
Now, it’s the 2010’s where tablets and smart phones are gaining ground but also users are becoming more demanding as far as their office independence (or space constraints, if you wish) is concerned. They now need or demand mobile applications that (like web applications before that) offer them more functionality with no compromises in security. Also, more and more people are attached to or dependant on their personal smart devices (since they are no longer used just for telephoning but also for storing and processing of data, such as calendar entries, to-do lists etc. to say the least). And these people wish to bring their devices to the workplace and carry them around, freely. So the “Bring-your-own-device” (or BYOD) issue is coming to the foreground of the CIO headaches. Different devices, many times in large numbers which is difficult to predict or quantify are coming inside the corporate environment, so CIOs must solve the security problems (to say the least) that are created by the diversity of these devices. Many times there is just no option of saying “no” to BYOD. Imagine the example of a hospital where customers/patients are coming in and are likely to stay in for hours or days. They just can’t be denied the use of their personal devices!
We don’t have to duplicate here statistics that can be found easily of the net about the mobile devices penetration and use. Just some facts:
- The number of smart device users is increasing in high rate. In fact, the rate is faster than the PC users of the 80’s or the 90’s.
- Soon, the smart mobile devices will be more than the desktop or laptop PCs on the planet.
- Mobile users in China have doubled last year, compared to the Japanese.
- Building mobile applications is very easy and there already are several frameworks that assist the development process and making it easier and faster; therefore cheaper.
- There is a large number of mobile apps that is offered for free (therefore it is easy for these vendors to build fast a “customer base”) and can be upgraded later for a small price (when the user will be convinced that the functionality is good and is there or wants some more). This didn’t happen with traditional web applications (although it is starting to happen with some SaaS products, nowadays).
On the above, add the projection that around 2025 we shall see a new kind of device. This is derived by the recent history of technological evolution. We don’t know yet exactly how they will be but we do know that they’re going to be mobile.
The above are showing us that mobile computing (and the relevant business/commercial applications, which is the main focus of this post) is the future. There will be a large number of players. Many of them will come from the emerging markets of Asia (with the low worker cost). In general, mobile computing will be the nursery for many new start-ups. In my opinion, we shall see a new “bubble”, the Mobile Bubble. There will be so many players that will be asking so much money (in investments) to build new ideas. Some of them will be interesting and some not. Some will float in the “ocean of entrepreneurship” and some not.
Like to dot-com bubble of the 90’s, I foresee a similar “curve” in the evolution of mobile applications. I quote a phrase which I recently came across: “For every good dot-com idea there were a thousand bad ones” and I add: Some very good ideas never made it to produce actual profit because of problems not pertinent to their technical completeness or quality.
It seems that the “curse” of mobile development is exactly the inherent advantages:
- It takes evolutionary and original thinking that usually young entrepreneurs have, who often do not have the qualifications or abilities of entrepreneurship, itself, so that they can build a viable business model.
- It’s a world trend, so all those technology people seeking to do something new inevitably turn their sights to this space. This results in a large number of start-ups which in many cases do not have clear business goals (or plans!), have limited resources etc. (Large players are still in development or marketing phase. Some of them haven’t yet come down in this arena as they are waiting to see where the “ship” is going to turn to).
- Modern tools make development easy but hasty decisions often result to poor user interface or user experience, in general. The average mobile or smart phone user is hasty and demanding enough, so a relatively good application which offers poor user experience is doomed to failure.
I believe that mobile computing has still a lot of ground to cover. However, definitely the future of computing is mobile (!) as devices are becoming smaller, smarter, faster, more autonomous and – let’s face it – a personal gadget that everybody wants to carry all the time, as they can combine business and personal activities with the best way. Finally, I believe that we are bound to see a “mobile bubble” in the current decade, which is going to clear the scene and, as always, prepare the world for the next technological leap. Let’s hope that we shall be here around 2020 to re discuss these issues once more!