General discussion


Signs your project is not ready for the cloud

By storm_rand ·
I work in a technical role for a very high profile Cloud/SaaS vendor (the self-proclaimed #1 in the Global Human Capital Market), so I’ve helped many clients with their first implementation of an off-premise web application delivered over the net. I’m always surprised at my clients lack of preparation and understanding of what they have purchased. Very often the expectations are completely misaligned with the services contracted. I’ve found that in many situations a decision to implement a Cloud/SaaS product came from a budget owner or CIO who wanted to be part of the “cloud evolution” and then handed that task down to a technical team to make it so. Since SaaS products are fairly new to corporate technical teams, it’s understandable that there is confusion, concern, and many questions when designing and implementing these complex technical solutions. So, I’ve put together a readiness checklist for any cloud implementation project. If you cannot check off the majority of items on this list your project - and your team - may not be ready for the cloud just yet.

You have a well defined and detailed service level agreement from your vendor(s).

It’s critical to have an SLA in hand so you know what is supported and delivered by your vendor. A good SLA should include a detailed list of the services delivered, installation sizing/capacity, the length and expiration date of the contract, service maintenance schedules, expected application availability, and support response times for reported issues. Oh, and stay far away from those SLA’s that promise to simply respond to your incident report within say 24 hours. If all you get is a response and not a resolution on a critical outage, your vendor isn’t providing you with service.

You’ve completed a vendor security assessment.

You’re moving data and functionality out into the cloud. How do you know that it will be kept secure and out of the hands of malicious persons? If there is a breach of data, how will that impact your business? A vendor that has addressed data security will be able to provide you with a detailed security control plan. Look for physical security controls (who has access to the data center and how its monitored) as well as application and data security. It’s not enough for a vendor to claim they have a security plan in place. Make sure the vendor can provide you with reports proving the monitoring and controls are in place, such as server and data access reports or logs when needed.

You’ve completed an integration and reporting needs analysis.

Cloud products are not data and functional islands. They supplement and often integrate with other cloud-based or corporate enterprise systems. An integration and reporting needs analysis should be a part of your implementation plan and should attempt to answer questions such as:
• How will you import data into the system?
• Will automated data feeds need to be developed and maintained?
• How will users be authenticated?
• What reporting data do you need and at what frequency?
• Is report generation and retrieval automated?
Remember to include a gap analysis to identify weaknesses in the service offering that may require significant manual processes or additional internal development.

You have a service escalation plan.

Problems will occur in the cloud. Networks will fail and applications will malfunction occasionally. Your team will need to know the procedure to follow when problems surface. An escalation plan will identify the impact or severity levels and the conditions that define those classifications, support and notification contacts, how and where to report a problem (email, support portal, support hotline, etc.), what should be recorded about the event, timeframes and conditions for elevation, and the escalation paths (internal and external).

You have an application monitoring solution.

Regardless of whether it’s an application in the cloud or not, you need a monitoring solution. Don’t expect your vendor to monitor all aspects of the application, including request/response times. There are a number of low cost monitoring solutions out there. You should monitor and measure average response times from more than one network access point for critical application functions such as user logins and frequent report requests. Consider setting up a monitoring solution that records the information to a database that can be analyzed at later date if needed. And don’t forget to monitor the application tentacles – authentication servers, integration feeds, etc.

Your business unit and technical teams are prepared for change.

SaaS products can be challenge to corporate technical and business teams as there is a shift in some of the responsibilities from corporate on-site teams to SaaS vendors. You teams should be prepared for this change and understand the division of responsibilities between you and the SaaS vendor. In addition, your teams should be prepared to adapt to a sometimes frequently changing application. For instance, some Cloud/SaaS products will go through multiple upgrades annually as part of the service agreement. Sometimes this will translate to user interface changes and feature removal, change, or deprecation. Prepare your user community - and your help desk - for that.

You have a project plan.

Project plans are critical tools for managing scope, cost, and delivering on target. Without a project plan you will most likely encounter frustration, delays, and cost overruns.

You’ve completed a cost benefit analysis.

Most projects that I’ve been involved with (I’ll estimate about 100%) have not completed a cost benefit analysis to identify the goals, performance improvement, and cost savings expected with a Cloud/SaaS product. Without a cost benefit analysis you will never be able to determine whether you’ve achieved your targeted set of goals and cost savings with the product.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Related Discussions

Related Forums