The Path to the Cloud with Enterprise Architecture Management: Part 2

Posted by Lesa Moné on December 18, 2017


Which applications to move to the cloud

After the resulting high-level capability model is agreed (figure 4), every capability can be taken and further fragmented to ensure the necessary level of details. A good idea is to create an Application Matrix showing the relation between business capabilities supported by cloud as well as by legacy on-premise applications in relation to specific user groups or locations. 

In Figure 1 below, varying colors indicate the functional fit. Legacy applications waiting for replacement by cloud alternatives are indicated in red. 

Screen Shot 2017-12-18 at 11.22.14.png

Figure 1: “Business Capability to User Group and Application Matrix revealing the “Unreasonable” applications which should be replaced by cloud solutions.” 

A modern enterprise architecture management tool may perfectly support you in assessing how ready your application portfolio is for the cloud and whether a particular application is well aligned with the overall business mission. 

To find out if and which applications you should or should not migrate to the cloud, you need to define the principal determinants for answering two questions: 

  1. What are the criteria to decide that an application goes to the cloud? 
  2. What are the criteria that prevent an application from going to the cloud?

Download the Enterprise Architect of Tomorrow Whitepaper Now!

This is a catalog you can apply to define the criteria that apply best to your company’s individual situation: 

Business Considerations 

  • Will cloud solutions be accepted by the business owner? 
  • What is the risk tolerance level of the business towards a cloud migration? 
  • What is the business criticality of the application?  

Application Lifecycle Considerations 

  • Is it still in the planning phase? 
  • Does the application need a technical refresh? 
  • Rather than migrating the application to cloud infrastructure (IaaS or PaaS), would it make sense to replace it with a SaaS solution?  

Application Architecture Considerations

  • Is the application web-based or built with a service-oriented architecture? 
  • Can it be split into modular services? What is the level of effort required to modularize it out? 
  • What are the demand fluctuations for the application? What impact will moving to the cloud have?

Data Considerations

  • Are there any confidentiality, privacy regulations that prevent moving to the cloud? 
  • Are the privacy or confidentiality concerns of the business? 
  • What is the level of data transfer between the application and the end user? Are there high load and lag considerations? 

Technology Considerations

  • How resilient does the network infrastructure need to be? 
  • Are there requirements such as network isolation, virtual private networks, elastic addressing and network segmentation? 
  • Is there a requirement for high availability and disaster recovery? 

Security Considerations

  • Who is responsible for authentication and authorization? Is there an SSO requirement? 
  • Which security controls are in place at the cloud vendor? 
  • Is continuous monitoring required?  

Integration Considerations

  • What are dependencies of migrated applications to other applications?
  • Is the migrated application a system of record for key data in the master data management scheme? 
  • Does the application rely on common directories, such as user directories? 
  • Applications used by mobile workers managing time and activity, contributing limited information 


Screen Shot 2017-12-18 at 11.26.42.png

Figure 2: “Cloud suitability”

Based on your individual criteria and assessments, heat maps can be created for the whole application landscape. They give you a full overview with regards to the readiness to move to the cloud-based on proper context, like business capabilities. 

Coping with technical obsolescence

Many organizations already have a large variety of technologic assets, as well as real estate assets to deploy them, as well as wired communication channels. A large number of infrastructure investments has been made to provide the best services to the customers. Because of that, a lot of decision conflicts must be resolved while transforming to the cloud and reach digital agility. 

Digital agility requires software-defined data centers to support extensive virtualization and automation of services, provided by data centers. Software-defined data centers enable computer virtualization to provide software implementation of computing instances, as well as software-defined networking, storage, hardware and automated administration. Taken all together, this provides corresponding services while abstracting from lower level systems. 

Screen Shot 2017-12-18 at 11.34.01.png

Figure 3: “Mapping applications to cloud providers help eliminate redundancies and estimate the impact of provider change.”


Cutting through technical and organizational silos

The next important question to consider is to investigate technical and organizational silos. This work should be focused not only on people but technology as well. The goal is to transform the silos into high-value reusable services, what in turn contributes to overall agility and allows to reduce costs. 

The Development and Operations (DevOps) practice promotes reusability and breaks down the silo’s walls. Previously, the Dev side was seen as the “makers” and the Ops side as the “people who deal with the creation after its birth.” Overcoming this silo mentality is the main driver behind DevOps. Other features of successful DevOps are a culture of cross-organizational services sharing, open feedback, automation, and constant metering of performance and processes. Cloud can help to cut through these silos by replacing infrastructure that is set up differently for each department. And of course by replacing locally different instances of business applications through on-demand cloud solutions. 

Screen Shot 2017-12-18 at 11.36.39.png

Figure 4: “Service layers and organizational silos.”


Some things to keep in mind 

While we are strong believers in the cloud, you should also not forget some problems that may arise. Your infrastructure service providers may not be your best friends when moving to the cloud, as cloud undermines their business model. Make them adhere to your strategy anyway. Try to find a the proper balance between the number of providers, products, and people required to deliver each service. Promote reusability in company’s services and capability landscape by firmly implanting this attitude in the teams. Wherever possible, delivery teams should reuse existing data sources, services, IT components, and other assets. You can support this reuse by compiling information on the available technologies in a central enterprise and IT architecture repository where all the teams have access to. The use of Enterprise Architecture tools is implicitly useful to succeed in developing your cloud strategy. Another important principle – applications and services must be almost independent of technology supporting them. All-in-all, these principles provide a good soil for further cloud transformation initiatives. 


Implement the cloud transformation

Enterprise or IT architects define, support and develop technology roadmaps. This supports the development of a shared and standardized technology infrastructure in your production environment and enables DevOps practices such as continuous deployment, automation, and operational monitoring. 

Screen Shot 2017-12-18 at 11.39.41.png

Figure 5: “Cloud transformation roadmaps allow you to see how your technology portfolio develops over time. Ensure that this development is suited to your DevOps strategy.” 

Creating cloud transformation roadmaps is the main architectural responsibility and task during the implementation stage as well as on previous stages. Further, enterprise architects coordinate the various projects of the developer and system administrator teams to execute the migration work. 


Govern and improve

This is the last stage we describe; however, it is executed not at the end of the transformation process, but rather in parallel to all the previous steps. 

Risks related to time losses, new technology use, as well as external factors, such as cloud providers must be estimated. Overall costs of the cloud transformation project should be budgeted and regularly monitored.

We recommend focussing on KPIs and costs metrics not only on the cloud platform itself as it can be hard to estimate agility and new operational models. However, what may become the main point of interest is the new organizational performance, determined in produced output and innovations per unit of time and costs. 



Cloud transformation creates an opportunity for new business models, innovations and increased level of customer satisfaction. Cloud is not just an IT related buzzy word anymore, it becomes the determinant of the business strategy. Cloud transformations are not easy to lead – it requires significant and timely efforts spent on redefining the business vision, needs, and culture. 

Every organization has its own cloud readiness level, which determines the first steps and benefits from the cloud journey. After that, you want carefully consider which applications and infrastructure to move to the cloud. We offer a catalog of business, application lifecycle, application architecture, data, and technology considerations. 

How to Measure Cloud Success