The CLOUD is here; it is here to stay, say and sway. Think about any business and chances are they are on the cloud already. Right from the simple web mail, to the moderately sophisticated Video collaboration tools, the Lync, sharepoint and other communicators, to the most complex CRM, ERP Dashboards, every tool that we use is on the cloud today- unknowingly, we are on the cloud more than we know.
With all its benefits of speed, flexibility, cost and variety, the cloud suffers from some drawbacks at the implementation level.
1) Contracts and administration: I believe there is still a lot of weakness in Businesses' understanding of cloud contracts. Applications that are outsourced to the cloud come with thick contracts, which are very technical and not too easy for businesses to understand immediately. For instance, how is the payment really scheduled? What is in-scope? The grayest of all areas lies around maintenance and changes. It becomes difficult to understand what truely constitutes a change request and what is indeed part of the support package. Is it surprising therefore that most businesses tend to never use all that they buy? The packaging, in my opinion, makes it difficult for businesses to buy exactly what they need- they land up buying a lot more and then never use everything they buy in a cloud contract.
2) Time to implement: Cloud applications dont simply "WALK INTO" a company. Its not as if a business decides to implement a CRM application, and it magically becomes available tomorrow. Cloud applications have to be IMPLEMENTED like any other. They have to follow the usual project delivery process that any business usually follows. This is mostly done by way of the usual application projects and typically takes months to implement. By any standard, any simplistic application will take 4 to 5 months at the very least, before the end user actually starts using it. This greatly diminishes the advantage that cloud applications bring- customized, off the shelf and READY TO USE. I like to use the phrase "This clouds the cloud"
3) Implementation issues: A common practice in many organisations in project delivery is to test the application from the point of view of security-the web applications testing as we commonly know it. This is where technical teams typically BREAK the application from various points- SQL Injection, un-necessry DB privileges, unsecured transmission of data, SSL implementations etc. While such testing is common place for in-house applications, it is not easy to test cloud based applications for such gaps. Cloud vendors sometimes have a problem with letting a technical team BREAK their application, for this may compromise the data of other customers, cause issues etc. A way around this is to have the cloud vendor provide a certificate from a 3rd party that his application is secure and follows the usual web application standards and guidelines. But this can be costly and the cost immediately gets transferred over to the client. One way or the other, cloud applications suffer from issues at the implementation level which mar their proposition of being cost-effective.
4) Support Model: Cloud and 3rd party applications are fundamentally changing the way support departments, or operations department are serving their end users. The concept of the HELPDESK is shifting fundamentally. Earlier, and for the longest time, every time an end user would face an issue, he would simply pick up the phone and call up the help desk. Or, he would log a ticket in his remedy system. But with the advent of cloud, support has moved to the 3rd party- indeed, this is one of the biggest value propositions of the cloud- to transfer support and ownership issues to a 3rd party so the business can focus on its core areas.
But this has its own complications. Because the application will be supported (read HANDS ON issue resolution), help desk and operation teams will not get totally familiar with the hands on issues of the applications-they aren't even expected to. In such a situation , whom does the end user call? If he calls the help-desk, are they expected to turn him away under the pretext that this is a cloud project and that he must call the vendor? If so, and if the user is indeed supposed to call the vendor support directly, this adds a change in the usual ways of working of the end users. This is something businesses don't like to see happen. This also involves training the end users to use the new ticketing system, and introducing the risk of having multiple such ticketing systems, one for each cloud application or vendor.
On the other hand, if the user still is expected to continue to call the help desk, then the help desk must be trained to route this issue to the vendor. This means linking the 2 ticketing systems together so that the vendor recieves the ticket without the end user experiencing a change in his experience. One way or the other, this involves BRINGING THE VENDOR into the business organisation- either by way of remote access ,or onsite support or something else. Either way, this adds cost and complexities, most of which must be borne by the business.
In my opinion, the last 2 issues- implementation related and the support model- will continue to cause disclaimers in cloud implementations. The entire cloud model must move to the next level of maturity to seamlessly integrate cloud applications with the usual ways of working within businesses.
With all its benefits of speed, flexibility, cost and variety, the cloud suffers from some drawbacks at the implementation level.
1) Contracts and administration: I believe there is still a lot of weakness in Businesses' understanding of cloud contracts. Applications that are outsourced to the cloud come with thick contracts, which are very technical and not too easy for businesses to understand immediately. For instance, how is the payment really scheduled? What is in-scope? The grayest of all areas lies around maintenance and changes. It becomes difficult to understand what truely constitutes a change request and what is indeed part of the support package. Is it surprising therefore that most businesses tend to never use all that they buy? The packaging, in my opinion, makes it difficult for businesses to buy exactly what they need- they land up buying a lot more and then never use everything they buy in a cloud contract.
2) Time to implement: Cloud applications dont simply "WALK INTO" a company. Its not as if a business decides to implement a CRM application, and it magically becomes available tomorrow. Cloud applications have to be IMPLEMENTED like any other. They have to follow the usual project delivery process that any business usually follows. This is mostly done by way of the usual application projects and typically takes months to implement. By any standard, any simplistic application will take 4 to 5 months at the very least, before the end user actually starts using it. This greatly diminishes the advantage that cloud applications bring- customized, off the shelf and READY TO USE. I like to use the phrase "This clouds the cloud"
3) Implementation issues: A common practice in many organisations in project delivery is to test the application from the point of view of security-the web applications testing as we commonly know it. This is where technical teams typically BREAK the application from various points- SQL Injection, un-necessry DB privileges, unsecured transmission of data, SSL implementations etc. While such testing is common place for in-house applications, it is not easy to test cloud based applications for such gaps. Cloud vendors sometimes have a problem with letting a technical team BREAK their application, for this may compromise the data of other customers, cause issues etc. A way around this is to have the cloud vendor provide a certificate from a 3rd party that his application is secure and follows the usual web application standards and guidelines. But this can be costly and the cost immediately gets transferred over to the client. One way or the other, cloud applications suffer from issues at the implementation level which mar their proposition of being cost-effective.
4) Support Model: Cloud and 3rd party applications are fundamentally changing the way support departments, or operations department are serving their end users. The concept of the HELPDESK is shifting fundamentally. Earlier, and for the longest time, every time an end user would face an issue, he would simply pick up the phone and call up the help desk. Or, he would log a ticket in his remedy system. But with the advent of cloud, support has moved to the 3rd party- indeed, this is one of the biggest value propositions of the cloud- to transfer support and ownership issues to a 3rd party so the business can focus on its core areas.
But this has its own complications. Because the application will be supported (read HANDS ON issue resolution), help desk and operation teams will not get totally familiar with the hands on issues of the applications-they aren't even expected to. In such a situation , whom does the end user call? If he calls the help-desk, are they expected to turn him away under the pretext that this is a cloud project and that he must call the vendor? If so, and if the user is indeed supposed to call the vendor support directly, this adds a change in the usual ways of working of the end users. This is something businesses don't like to see happen. This also involves training the end users to use the new ticketing system, and introducing the risk of having multiple such ticketing systems, one for each cloud application or vendor.
On the other hand, if the user still is expected to continue to call the help desk, then the help desk must be trained to route this issue to the vendor. This means linking the 2 ticketing systems together so that the vendor recieves the ticket without the end user experiencing a change in his experience. One way or the other, this involves BRINGING THE VENDOR into the business organisation- either by way of remote access ,or onsite support or something else. Either way, this adds cost and complexities, most of which must be borne by the business.
In my opinion, the last 2 issues- implementation related and the support model- will continue to cause disclaimers in cloud implementations. The entire cloud model must move to the next level of maturity to seamlessly integrate cloud applications with the usual ways of working within businesses.
