At Txture, we are typically working together with members of the cloud center of excellence (CCoE) of large organizations. These teams are formed to push the journey to the cloud forward. They typically start with defining the cloud strategy and then move on to assess the cloud readiness of the application landscape. In most CCoEs, we see enterprise architects as an important and core part of the team. As an enterprise architect one is uniquely positioned for cloud assessments. You know your IT landscape better than most people in your organization. You have an understanding of the interfaces between applications and hopefully also what kind of data is transmitted. We want to briefly introduce you to the key aspects of cloud assessment and provide you with the methods and tools to execute it at scale.
Let’s start with the definition of my (and for that sake Txture’s) understanding of cloud assessment. When I talk about cloud assessment, I mean the holistic analysis of applications or entire application portfolios with regards to how easy it would be possible to move them to the cloud, what costs would be involved and what other implications the transformation might have. This is typically a quiet exhaustive task. But the work pays off! Only through such in-depth analysis, one can make informed decisions if it makes sense to move an application, not only from a technical point of view but also from the business, security and compliance perspective. Of course, there are some examples where such an in-depth analysis could be overkill. For example, if it is clear that the lease of a data center runs out, such that it is clear that all apps need to be moved. But generally, speaking an in-depth analysis is crucial to avoid costly surprises during and after a migration.
So what will you get out of a cloud assessment? The deliverables are typically recommendations of appropriate cloud providers, the migration effort, possible target architectures and most importantly a categorization with respect to the 6Rs of cloud migration. If you don’t know the 6Rs of cloud migration, check out our blog post, but let me introduce them to you real quick.
Generally speaking, the 6Rs define if or how an application and all of its components are to be migrated. Each of the “6Rs” entails a different way of migrating or not: rehost, replatform, refactor, repurchase, retire/rationalize, retain. Here are some examples to get you up to speed:
Now that you know the key deliverables, let’s look at the fundamental assessment criteria.
In order to really make these 6R decisions, each application needs to be analyzed from four key dimensions: business & organization, compliance & privacy, security and technology. The difference between these viewpoints and the data that you typically collect as an enterprise architect is the level of detail. Whereas in most EA use cases it is enough to know which high-level technology an application uses (e.g. MySQL + Tomcat), in the context of cloud transformation the exact deployment stack and all interfaces including their security configuration and requirements need to be known. Let’s look at each dimension in more detail.
In this viewpoint, you need to get a clear understanding of who uses the application for what in your organization. Some key questions to consider are:
These are just a few examples of what needs to be considered. As you surely realize, this is a clear business enterprise architecture territory. If you have a well-documented application repository, you should be able to draw some of your basic information from there.
Here we get a bit more into the complexities of outsourcing your computing and data to a cloud provider. There are two main aspects you will need to consider for each and every migration decision to get this right. First, you need to know the certification requirements for the application and all its (transitively connected) components. This is already where we leave the typical realm of EA. As an example, let’s consider you are looking at the application portfolio of a German bank. The bank falls under diverse regulations from the Bafin (such as the BAIT or the European Banking Authority. In many cases, these require each outsourced service to be certified in a specific way such as with the C5 criteria catalogue for cloud. Now this leads to the question for each application if these requirements can be met by a specific cloud provider, for each component of the application and in the desired deployment region! This is often already a very complex question to answer because an application can consist of many components and each deployment region of the cloud provider has different certifications per service. A cloud service in Germany might have different certifications than the technically same service in Ireland.
This brings me to the second aspect: privacy considerations, for example with regards to the GDPR. It is crucial that you know what kind of data an application processes and where it is sending it. If you are dealing with Personal Identifiable Information (PII) there will be strict rules on which cloud deployment regions you will be legally allowed to process that data. So in the context of cloud readiness assessment, you need to be even more aware of the data processed by a technical component. If you don’t have this kind of data available, I suggest getting in touch with the data privacy officer in your organization to identify synergies and avoid duplicate data collection - which leads over to the related cloud readiness dimension: security.
Besides privacy, security concerns are among the most raised questions with regards to cloud transformation. Indeed, if overlooked, there can be severe consequences, because the devil lies in the detail here. First of all, it is crucial to know the actual interfaces between applications, their security mechanisms and the data they transfer. We are not talking about the high-level interface concept of most enterprise architecture tools. We need to assess the actual point-to-point communication technology on the application component level. Then we need to inspect the encryption technology that is in use (if any). Depending on the type of encryption we can often identify how much refactoring needs to be done to make an application ready for the cloud. Another important consideration is the information security relevance of the stored or processed data. Is it a business-critical or core intellectual property of your organization? If this is so, you might want to consider keeping the data in a private cloud or on-prem.
The technical dimension is probably most distant from a typical EA. Although, enterprise architects (rightfully) aim to abstract away the technical complexity of their application portfolio, for the purpose of cloud assessment, the details must be considered to make correct decisions.
That means for making transformation decisions and analysing the cloud readiness of an application, the entire technical stack including the interfaces to other applications must be known. As a first win, this gives you an overview of the overall application complexity, which is an important factor for calculating the risk and timeline of a migration. Here are some key technical aspects to consider for the technical cloud assessment.
In addition to the cloud readiness aspects, of course a key aspect is the Return on Investment (ROI) calculation by comparing on-premise costs with the transformation costs and operating expenses (OPEX) in the cloud. The introduction to this topic I leave for a separate blog post since this a whole new can of worms.
Summing up, we hope we have given you an overview of the key aspects of cloud assessment from an enterprise architecture perspective. As you can see there is quite an overlap, but much more (technical) details need to be collected to actually make the right decisions.