And this is all the more true given that cloud projects are far from neutral in budgetary terms. Choosing the cloud is not something to be taken lightly: it can make sense for some applications, and be totally useless, or even counter-productive, for others. The study must be carried out application by application: a role for the enterprise architect.
1. Manage cloud migration priorities
The usefulness to business teams – in other words, business criticality – is naturally the first thing to measure for a cloud migration: why build a project for an application that is rarely used or brings little value to the business? On the contrary, a core business application gains in durability, efficiency, flexibility and scalability by migrating to the cloud. This is the promise of this option: spending less time on infrastructure issues and more time on functional changes.
This value is also measured over time: a core business application that is at the end of its life cycle, despite its value, will not be migrated, but replaced by a “cloud native” application. Conversely, an application that is still immature or lacking in stability (functional or technical) should not be a priority for a cloud migration. In this context, the enterprise architect will be able to finely evaluate the life cycle of each application to decide whether it is appropriate to launch a migration project.
2. The complexity of the application, determining the project load
If a migration project is far from neutral for the organization, it is even less so the more complex the application concerned. This complexity is measured first and foremost in terms of the components of the application itself: the technology used for its development, the level of specific developments or customized features, etc.
Measuring these elements allows us to evaluate the workload of both the IT department and the business teams, who will be required to contribute to the migration, according to the possible types of strategy: “rehosting” (rehosting or switching), “replatforming” (to a native cloud platform), “re-purchasing” (new product), “refactoring” (or redesigning the architecture). On the other hand, it can also be decided to decommission the application (“retire”) or to keep it as is (“retain”). Together, these six strategies (“6Rs”) make up the possible options for cloud migration.
But the complexity of an application can also be assessed by its position in the information system and its interconnections with other elements of the IS. For example, a CRM or an ERP is inherently complex, because it interfaces with many other applications, and even with the company’s ecosystem. This also makes them more difficult to migrate. Here again, the work of the enterprise architect in terms of IS mapping is a valuable tool for evaluating migration possibilities.
3. Data sensitivity: managing risk and compliance
Finally, it is also the data that will have to guide the organization’s choices when it comes to cloud migration. Because the process is far from trivial in terms of governance, risk management and compliance (GRC). In some cases, this is simply not possible, at least not for public clouds: sensitive business sectors, operators of vital importance (OIV) or operators of essential services (OSE), public administrations, etc.
When it is possible to move data to the cloud, whatever the sector concerned, the enterprise architect must ensure that security aspects are managed effectively: migrating applications, and therefore data, does not mean delegating the entire security of the IS to a third party. On the contrary, it is even a matter of redoubling vigilance.