Working with Cloud in an Enterprise Environment and involving different Personas

Xavier Geerinck -

While startups might merge different personas into the same profile to optimizing spendings, enterprise organizations are more complex. They typically offer a structured approach on how applications are developed and deployed. In this post I want to provide insights on how an enterprise environment typically works and the different teams that should be involved to be able to deploy a cloud application.

The Startup to Enterprise Development Journey

Imagine you are a startup organization, typically you are with just 1 or 2 people managing the entire - sole - application. You thus create a deployment script and create the application that you than deploy on the cloud environment.

While this is ok to start with, it does not scale when the organization grows. When growing, certain aspects come into play:

  • How do you reduce code-sharing overhead
  • How do you remove the requirement for profiles to know infrastructure deployment, application development, ... since these are difficult profiles to find in the job market
  • How do you reduce the different number of technologies being utilized (e.g., you might start off with Node.js, but while growing other developers might introduce Python for AI models, C# for certain backends, ...)
  • How do you ensure different applications can interact with each other?
  • How do you keep track of operations on the larger amount of applications?
  • How do you keep spendings under control?

Does any of the above sounds relevant to you? Congratulations on becoming an enterprise company! 🎉 This is where structure comes into play to ensure processes are introduced and people can still grasp the complexity of all of the above.

From Architecture creation to Application Deployment

Program Manager / Product Owner

In an organization there is typically a Program Manager / Product Owner taking care of defining the product (application). They take care of navigating through the process of collaborating with different teams, creating a product spec, and ensuring this product eventually gets to production. While this might sound as an easy task, the Product Owner's role is often seen as one of the most complex ones as they are responsible of inter-team communication and ensuring their vision becomes reality.

Application Lifecycle

While creating an application the Product Owner has a specific track they should navigating within the organization. Let's go through the illustration below:

The teams involved after an initial product specification is created are:

  1. Architecture Team: Before you can get started, you typically pass through an Architecture team that helps you build an architecture for your application. Their goal is to ensure components are streamlined across the organization and IP as is being reused where possible.
  2. Center of Excellent (COE): Once an architecture is provided, you want to request access to the Cloud environment. The COE team their scope is to provide you this access and offer a way of working on how you should deploy your applications.
  3. Platform Team: An architecture has been created and access has been provided through a COE. Now it's time for the Platform team to assist you in deploying these components in a way that is both scalable and upgradeable. Typically, Infrastructure-as-code (IaC) tools are being used here such as Pulumi, Terraform, Biceps, ...
  4. Application Team / DevOps Team: The infrastructure is ready to host your application, we can now instruct the application team to deploy the application through separate tooling. Here we typically see DevOps pipelines being created for a CI/CD pipeline (Continuous Integration) that helps you redeploy your application once its version changes.
  5. Operations Team: Finally, your application is running in your environment (development, staging or production) and it's up to the operations team to ensure that everything is being monitored and errors are being triaged accordingly to ensure uptime as well as bug resolution.

Infrastructure vs Application

💡An important thing to note about the above is that in your typical application creation journey two important steps are isolated:

  1. Infrastructure Deployment (IaC)
  2. Continuous Code Deployment (CI/CD)

This happens since multiple teams are involved. One team - the infrastructure team - ensures that your architecture becomes reality (the infrastructure team) who should as well take care of updating this independently from your main application.  They collaborate with the Architect to create your components that provide the backbone of your application.

Next, the application development team ensures that code can be created and deployed on that provided infrastructure.

Summary

While the above might all have seemed trivial, an important aspect to remember is that applications have a development lifecycle where we should unblock as many teams as possible, reducing the dependencies on each other. When decoupling the Infrastructure from the Application deployment, you can let the infrastructure team work in parallel from the application team, increasing your Go To Market and reducing the overhead (and frustrations).