Data

Another dimension to be considered when moving to the cloud is your data, which exists in different forms, including the intellectual property rights that apply to applications developed in-house, such as algorithms or procedures that have been implemented. As mentioned before, the employees of a cloud provider can theoretically access the infrastructure, so another concern is the extent to which a company can trust the multitenant capability of a cloud technology. With third-party software, it's a little easier; admins can assume that cloud-suitable licenses, support contracts, and subscriptions fully address this issue.

A second category of data includes the information that your application receives, processes, and shares, which could come from your own company or from customers and partners. This category also includes data on the structure, configuration, and topology of the infrastructure and the layers above it.

Possibly, some data is not worth protecting. This decision is rarely binary. Typically, access to data may be (a) intended for the entire public, (b) only for the company's own customers and business partners, or (c) only for the company or parts of its workforce. Further gradations are not unusual.

The nature of the data also plays a role. Does it contain personal information? If so, what compliance legislation needs to be considered? For example, a new European Union (EU) Regulation on General Data Protection (GDPR) [6], which comes into force in May 2018, states that if credit card information is involved, then Payment Card Industry Data Security Standard (PCI DSS) [7] immediately takes effect.

In the face of such industry standards and laws, a company must understand the breadth of responsibility of the cloud provider and where it ends, how it secures the cloud, and the extent of in-house IT obligations.

Amazon spells out the PCI DSS case when using AWS as a service provider (Table 1 [8]). In addition to these standards, you must consider any contractual agreements or country-specific laws governing the processing, transmission, or storage of certain information, which could require another type of data classification.

The availability topic mentioned above can also play a role. For example, if problems occur in a cloud data center in Germany, will a recovery then take place in France, China, or the US? What do you do if the data is not allowed to leave the country, as in the case of the AWS London region described above?

The volume of data also needs to be taken into account. Domestic IT incurs almost no costs for data transfer, which makes savings considerations meaningless. However, data that flows into or out of the cloud requires a thorough analysis of the transit information, which can sometimes be very time-consuming, especially in mature environments. Moreover, data traffic cannot be reduced without changing processes or workflows.

The analysis sometimes also affects the software used. In the worst case, an IT department would have to turn their processes inside out to save, not increase, costs in the cloud. The question of data processing design is therefore also an important point in the catalog of requirements.

Compared with migrating software, preparing to migrate data (categorization, data entry, data flow analysis) is a mammoth task, yet absolutely necessary before you can attempt to join the cloud.

Connected to software is the integration of data analysis and mapping of in-house applications. An existing inventory of the software (a configuration management database, CMDB) [9] should contain this new information. Cloud providers and other service providers only provide limited help in such cases, because a great amount of in-house knowledge is required for this task.

OSI Layer 8

After software and data, perhaps the most frail aspect of the path into the cloud is the human being. Once the infrastructure is in the cloud, it is no longer your own employees who handle firmware upgrades for the hardware, lay cables, and bolt the bare metal into the rack. Who monitors the cooling or takes care of the zoning?

A few traditional jobs in an IT landscape are no longer necessary, and it doesn't look any better in the higher layers of the technology stack, either. The cloud service providers offer ready-made images for various Linux distributions and Windows versions, which are part of the cost of the overall package. Traditional procurement of operating systems becomes superfluous.

These changes explain the skepticism or perhaps even worry that lies along the path to the cloud. Software and decrees cannot solve this challenge. Instead, management must reorganize IT or even the entire company, because an infrastructure-centric approach will no longer work in the future when these tasks are outsourced.

Basically you have two approaches: outsource your own cloud activities to a new company – which makes it easier to set up new processes, approaches, and procedures, regardless of legacy issues – or change the organizational structure. The first case adds organizational overhead (e.g., in human resources) and, worse, risks building a two-tier society. You are only safe if you work for the Cloud Team. Traditional IT is then considered uncool and threatened with extinction.

In the second case, the interfaces to your own infrastructure ideally are similar to those of the cloud service providers so that the focus shifts toward the business application and the customer. Internal IT follows the same or at least similar principles as the cloud provider (i.e., established AZs, regions, etc.).

Reorganization is not just a matter of paperwork, however, even if the disadvantages of the first approach are less important. However, both options open up the possibility of installing new or adapted processes and workflows that let you turn sys admins into cloud engineers, database admins into data scientists, and application administrators into automation specialists. In this way, old roles and positions are dropped and new, future-oriented responsibilities are created.

Some approaches, practices, and methods have proven their value in the context of the reorganization dilemma, including bimodal IT [10], DevOps, two-speed IT, or lean and agile. This variety of solutions suggests that transformation is simple and only the right tools are needed. Quite the opposite is the case, in fact. The focus is on people, employees, colleagues, and bosses.

Conclusions

Now the article comes full circle: What problems with your existing IT infrastructure do you want the cloud to solve? What are the expectations? Which goals do you want to achieve? Far-reaching changes can be implemented more easily in companies if the necessity and the background are clear and sponsors can be found across the organization.

The way to the cloud is possible, but the challenges are not to be underestimated. The motivation should therefore be comprehensible, beginning with your own staff, but also including partners, service providers, and customers. Managing software and data in the cloud requires changes, customization, and a large amount of homework, as well as new processes, workflows, and approaches. The knowledge and experience gained in operating your own IT landscape is useful, but the central component is and remains the company workforce.