Txture Blog

Cloud Migration

All articles
Cloud Knowledge

Cloud Assessment for Enterprise Architects

7min read
2020-04-15
Share this article:
enterprise architect during cloud assessment

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. This blog post is for these enterprise architects that are or will be tasked with assessing their IT landscapes for cloud readiness.

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. In this article, I 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.

Cloud Assessment

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 previous 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:

  • Rehost example: copy/move a VM to an IaaS virtual machine
  • Replatform example: use a PaaS service to replace on-prem DB
  • Refactor example: rewrite the application to run containerized on Kubernetes
  • Repurchase example: replace on-prem Atlassian Jira with SaaS version
  • Retire/Rationalize example: shut down an application because of duplicated functionality after a merger
  • Retain example: keep application as-is, e.g. because not enough data is available to make a decision

Now that you know the key deliverables, let’s look at the fundamental assessment criteria.

The four dimensions of cloud readiness

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.

Business & Organization

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:

  • What would be the business benefit for a particular application to be moved to the cloud? E.g. would the ability of horizontal scaling or dynamic instance down-sizing have a large impact on your bottom line? Would it make you more agile to innovate?
  • How many users log in to this application and from where? Is this number increasing or decreasing?
  • What’s the lifecycle of the application? Does it make sense to migrate it if it will be retired next year anyway?
  • Is there potential for application rationalization via the migration? Does another application provide the same functionality?
  • How business-critical is the application? Will a migration be risky and a threat to business continuity? Or very simply: do we know the application owner to ask these questions?

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.

Compliance & Privacy

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.

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.

Technical

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.

  • What is the virtualization degree of the application? Does it run on bare metal or even a mainframe? The latter typically makes the cloud transformation harder or even impossible.
  • What are the high-availability requirements of the application, would it be easy to containerize the components?
  • Are there replacements for each of the application’s components in the cloud? If not, major refactoring might be needed.
  • What is the size of data that is stored by the application? In some cases, the size of the stored data is prohibitive for a migration.
  • Is the source code available for potential refactoring? If it is not available a migration might not be possible since the necessary changes to the code cannot be applied.
  • Is the application stateful or stateless? Stateless applications are typically easier to migrate.
  • Does it make use of technical components that are end-of-support life, or will be hitting it soon? If this is the case, the migration might be more cumbersome.

The above list is only a fraction of the typical questions that need to be answered in order to calculate the technical cloud readiness of an application. A full list would certainly blow the scope of this blog post.

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, I hope to 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.

In practice, it is quite challenging to discover the necessary data and make sense of it. So, in case you need a structured approach to data collection, cloud readiness assessment, cloud business case calculation, cloud cost optimization, cost forecasting and cloud target architecture generation, please get in touch with us. Our platform Txture automates most of these cumbersome tasks for you!

Matthias Farwick
Author
Matthias Farwick
Dr. Matthias Farwick is co-founder and CEO of Txture. Before founding Txture, he worked in R&D projects in Austria, Canada, China, Germany, and the United States. He has published more than 30 scientific articles and book chapters in the context of enterprise architecture management and cloud transformation.