From the technological perspective, any remaining skepticism is diminishing. Cloud transformation makes sense. So why do so many cloud projects still end in failure? Is the necessity to involve people neglected?
Any company that decides to migrate a major part of its IT to the cloud needs a cloud operating model. This is indisputable. But how should this model be designed for a specific situation? This is where opinions diverge. The clash of convictions in conjunction with the lack of standardization guidelines is why there is a range of process models rather than the one and only cloud operating model. Why (as determined by various studies) do at least half of all transformation projects fail utterly or at best fall short of delivering the desired benefits? And many a cloud project ends up being the source of higher costs, exactly the opposite of what the cloud was supposed to bring.
Technology is not everything
There can be any number of reasons such as unreasonably high expectations of companies and individual departments. Ultimately, however, the majority are doomed by a fundamental orientation of the cloud operating models that views the transformation almost exclusively from the technological perspective. One of the factors driving this approach is the development of the models (by and large) by the cloud operators themselves, and the attention of hyperscalers such as Amazon, Google, or Microsoft understandably focuses first and foremost on the technology.
But technology is only one pillar of a transformation to the cloud. In terms of technology, many companies now succeed in converting their previous on-premises infrastructure into that of a hyperscaler without encountering any significant problems as there are more than enough best practices available for a wide variety of IT constellations and industries. The often rude awakening follows later. Booking new virtual servers in the cloud is easy. But the move from the company’s own data center to the cloud entails adapting the organization of IT and business departments to new working processes and new opportunities.
Many teams have never previously collaborated across departmental boundaries, for instance — because there was no need or even no desire to do so. IT teams now require additional qualifications, and the consideration of governance aspects is no small matter, either. If these issues of a transformation are disregarded, the technology will not be the stumbling block, but ultimately, the hoped-for benefits will not materialize.
Thinking and working too much in silos
The cloud is only too willing to promise alluring advantages: companies will become faster and more agile, and they will significantly shorten time-to-market for new products and services. Virtual machines that can be realized with a single click, however, are inadequate for achievement of such targets. If IT teams continue to work in their silos, there will be little change in the way they work. Retaining the procedures of the past for ordering new resources — using traditional channels such as sending an email to the IT department — are only one example. Another is when employees must overcome numerous internal hurdles to access much-needed resources.
Such companies do not have the appropriate decoupling of operational and financial processes that would allow teams to manage their own budgets and to determine how much money they need for prototyping, product deployment, and other activities. Or they do not have overarching governance regulations. In other words, the change is much more profound, involving processes that allow teams to manage their own resources. Cloud transformation must break down silos and enable teams to use the cloud and work in the cloud according to their own needs. Self-service replaces a centrally managed warehouse.
IT and business departments need additional know-how
The establishment of new processes starts with the IT departments. While before the cloud era IT teams had enough to do in setting up and managing their own infrastructure, many of these activities — laying cable in the data center, ordering and assembling hardware and network equipment, preparing patches and upgrades — are no longer required. An entire department to deal with such basic “manual” tasks is no longer necessary. Now DevOps engineers can execute lines of code and launch operation of the virtual machine. They deal now with APIs, not with people. And the complexity involved in obtaining a resource has been enormously reduced.
Previously, IT teams were strongly focused on their technical expertise. Cloud operations require them to supplement this knowledge by becoming familiar with business processes and creating a mix of IT and business expertise. On the other hand, the business process specialists from the various departments of the companies — purchasing, logistics, production, sales, etc. — must acquire more IT skills. Otherwise, the skills gap on both sides will cause cloud projects to fail.
Four pillars of the cloud operating model
So what does a successful cloud operating model look like? It defines how an organization interacts and involves partners within the cloud ecosystem comprising people, processes, and technology. The operating model should not be content to map the technical aspects of a cloud transformation. It consists of four pillars: governance; organization and culture; processes; and roles, skills, and tools.
The cloud governance model lays the foundation for the interaction of all cloud-related organizational units in accordance with rules and policies. It provides the framework for cloud deployment and operations, security and cost management, and management of ecosystems, including partnerships.
Organization and culture pillar focuses on people
The organization and culture pillar defines what form the organizational design and interaction among all cloud users should take and how they can interact effectively and efficiently. An organization built on rigid silos prevents companies from becoming more agile in their actions and decision-making. Silos prolong the duration of a cloud transformation or may even cause it to fail altogether. Often this is a consequence of different “cultures” within each of the silos, a situation in which the silos do not communicate with one another and have other issues.
Trim process architecture for agility
The process architecture pillar is based on successful agility principles. Defining agile processes is a key element of a successful cloud operating model and are the fundamental starting point for the creation of mechanisms for process monitoring and quality control. The causes of a lack of agility in processes can be traced back to weaknesses that are similar among many companies, including a lack of KPIs providing information about the quality of individual processes and that may require adjustment. This even goes so far as to neglect the significance of customer satisfaction as an absolute target figure.
Train cloud skills and deploy simple tools
The fourth pillar, “Roles, skills, and tools,” once again focuses on people. Regardless of product owner, tech leads, or DevOps, roles are clearly defined and communicated in this element and include comprehensive learning and training opportunities. Generally speaking, there is a lack of business-related cloud expertise in the business units outside IT at the beginning of a cloud transformation. Since IT competence was previously almost exclusively the purview of the IT teams, the business departments know little about the options the cloud offers them. Companies need to close these cloud skills gaps.
How mature is the organization for the cloud?
And how can these four pillars be realized? By conduct of a comprehensive assessment, a cloud maturity check, in which the current status is carefully examined. Drawing on the conclusions of this check, an existing cloud operating model can be redesigned or a suitable one introduced before it is finally implemented and rolled out.
Time and time again, such projects reveal that companies have long been in the cloud, that there is even formally a cloud operating model, but that it has never been applied, even though it considers the transformation from more than just a technical perspective. Some have even tried a model, but failed. If that has happened, we want to know how and why it failed. Perhaps the model itself was not at fault. Once this preliminary work has been completed, a road map with a timeline and realistic goals is created. Typical results that can emerge from holistically built cloud operating models include clear guidelines for security and costs, unambiguous KPI and service levels, and a viable basis for agile, flexible action in the cloud that is also designed for collaboration with partners.
