5 lessons for cloud success

6-minute read

Consensus: Everyone is moving to the cloud and reaping benefits of both effortless scalability and significant cost savings.

Reality: The majority of cloud initiatives are over budget and under-utilized. The few successful migrations will require one to three years to show a positive ROI.

Historical context: During gold rushes, the best way to become rich was to sell mining supplies. Of the 10 largest technology companies in the United States (according to CNBC), nine have cloud services and/or product offerings.

The gold rush analogy is accurate in that those who provide goods and services in a booming market are those who make the earliest and largest direct profits. It is flawed in that moving to the cloud can always be done successfully with the right guidance.

The specific, detailed steps of a journey to the cloud ending in improved business capabilities and profitability can vary greatly for each enterprise (and even among divisions within the enterprise). Consultancies like Logic20/20 — with long experience in trail-blazing — can make a huge difference in the quality of that journey. Across all the possible routes to cloud nirvana, there are some common goals and experiences, which we will describe here.

Lesson 1: Pick the project before choosing the tool.

Another difference from the gold rush days is that the merchants back then did not go to people and tell them they should go hunt for gold. The miners had a goal and went looking for supplies. There are many cloud initiatives that have begun because a vendor came to an executive and convinced them that Product X and Service Y will fix all the problems in System Z. And the salesperson knows this because the product manager told them so, with slides and trainings produced by the marketing department. Everyone involved really believes they are doing the best thing; they just may not be aware that the problem they are solving isn’t the problem that needs to be solved. This is the start of a failed cloud initiative.

A successful cloud initiative begins before the cloud is considered, or at least when a business case is made before licenses are purchased. This can also depend on the group doing the work and the context. An enterprise architecture group evaluating current capabilities that would benefit from a move to the cloud makes sense as long as the benefits are measurable with metrics that support business needs. The best chance of success comes from a new business initiative in which a cloud offering provides the best support for implementation. For example, a financial services company offering tax-related services that will be resource-intensive once a quarter, but seldom in between, could recoup costs of development faster using a cloud-based serverless architecture coupled with an elastic web server cluster to manage increased traffic during times of heavy use.

Lesson 2: The secret to the cloud is that there is no cloud.

The t-shirt proclaiming “There is no cloud — it’s just someone else’s computer” is a valid over-simplification of the reality. The cloud everyone refers to of late is a loosely defined collection of services that is vague in nature. It originates from the architectural diagram used to indicate systems in use that are beyond the boundaries of direct responsibility. In the modern version of this diagram, the direct responsibility lies in defining what and how much you will be paying for others to be responsible for.

Where companies run into trouble is in understanding (or not) how this new boundary is defined. Business is accustomed to allocating funds to IT and then having someone in IT responsible for everything from top to bottom. With cloud services, the service provider is responsible for providing what is asked for within the parameters of the service offered. Customization is owned by IT (or the business, where citizen development is in play). If a business service fails because insufficient resources were contracted for, it is the responsibility not of the service provider but of the service consumer. If the costs of cloud services exceed the costs of on-premise solutions because the capacity was overestimated, it means the business process for procurement needs to be fixed — it’s not because the vendor is charging for unused services. Moving to the cloud is a cultural shift as well as a process shift.

Lesson 3: The platform is not the implementation.

Managers and business team members are often unclear on the distinction between the cloud platform itself and the implementation of that platform. This is often exacerbated by issues reported with wording that implies the platform is the root cause. This misunderstanding can lead to time, effort, and (worse) decisions being made focused on the symptom rather than the cause.

For this lesson, let’s use a specific example to keep it concise, and leave it the imagination to find the parallels that exist in all PaaS, SaaS, and IaaS architectures. On a recent project there arose an issue where the governance limits of the platform were exceeded. When the vendor (Salesforce) notified the customer, a temporary limit increase was allotted to allow time for addressing the issue with a better design. But the customer did not attempt to address the issue; the new (temporary) limit was exceeded and the application began to fail. Then the customer was upset because Salesforce would not further raise the limits without a hard date to address the issue.

Salesforce is a mature, robust, and feature-rich example of much that is possible in the cloud. They were one of the fastest-growing technology companies this year because they sell based on their reliability, scalability, and performance, and businesses feel confident buying their services. Salesforce is also one of the most customizable and most often-customized services around, and the costs of implementing and supporting those customizations are frequently much greater than budgeted for. Why? Because the best practices of planning, design, testing, delivery, and support that are generally implied for an on-premise system are minimized or abandoned for systems deployed to the cloud. When results are disappointing, it is surprising how often the blame is put on the platform.

Lesson 4: Training is free and necessary.

Almost every major cloud platform provider offers free training. They also share the selling point that the development languages they provide for implementation are either commonly used or proprietary with very similar syntax to a commonly used language. The optimistic project manager might believe this requires little or no training budget. The reality is that the languages are standards-based to accelerate the understanding of all the specialized libraries and patterns necessary. Knowing how to iterate over a data set or parse a service response is common across platforms and architectures. The question of where to do this in the implementation process is often platform-specific and always needs to be reviewed against how the platform will work when all components are not running in your own datacenter.

A specific example that comes to mind is using Informatica Cloud Data Integration with Salesforce. ETL teams who are well-versed in on-premise implementations create lookups against Salesforce data … and then blame the platform for the poor performance and the documentation for not pointing out that this is an anti-pattern in cloud-based ETL. However, this is covered in one of the earliest lessons in the free Cloud Academy training provided by Informatica.

It is important that project plans include training time up front, and that completion of relevant courses be made mandatory. The middle of a project is a painful time to realize that the specific differences are broader than anticipated based on decisions driven by budget-consciousness or over-generalization.

Lesson 5: Establish monitoring and metrics before go-live.

Perhaps the biggest advantage of cloud services is the ability to scale quickly. Following the first four lessons will help in establishing an architecture that can take advantage of this flexibility. There are a few truly elastic services that will adjust capacity and costs automatically as part of the service. They are in the minority. Understanding how to manage the contracted services and monitoring them in a manner that matches the business model the service is supporting will provide valuable guidance on when to decrease capacity to optimize cost margins, and when to increase capacity to avoid costly and embarrassing outages.

Before you begin

Most people have taken a test that starts with “Read all instructions before beginning” and concludes with a very simple instruction with many time-consuming steps in between. You can tell those who didn’t follow the instructions because they are working diligently long after those that did are finished. This article is like those instructions. All of the lessons above would, in any other context, be considered common sense. When the IT industry gets excited about something that is new, powerful, and valuable, many enterprises jump in and start using it. Months or years later, they look up from their struggle to see those who started later and engaged help from strategic, mindful partners are reaping the rewards of skipping the rush and going straight to the practical.

Senior Director Scott Nelson has over 20 years of experience working with the full delivery life cycle of solutions for system integration, process automation, and human workflow applications.