Organization topologies for enterprise-scale cloud consumption
Economies of scale give an organization standardization of technology and patterns and the ability to use it across multiple teams and purposes, for example — a standard software for documentation, a platform service, a documented architecture pattern, or a standard method for project management. Economies of speed provide agility to teams to execute their goals faster. Speedy execution often requires building something custom that another team rarely reuses. Many IT organizations have realized that balancing speed and scale is not easy, and they select one to meet their business goals.
One of the most significant draws of cloud computing is its ability to provide self-service to instantaneous infrastructure. However, as organizations start using the cloud and scale its usage across their organization, finding a balance between scale and speed can become a challenge. This article discusses ideas and patterns on how team structure can provide speed-to-scale efficiency in a cloud-first enterprise.
Also, it will be a good idea to lay out a few ground rules for building efficient organizations and structures. These are five of those which I gathered over the years working across small and large product delivery teams -
- Teams need to know their purpose and how they can continuously show value as they execute. They also should understand how they connect back to the big-picture of the organization’s strategy.
- Over time, individuals in teams find their group dynamic to work together, execute and increase throughput. Seeing this dynamic always will take time; letting it happen is a good investment.
- Product delivery will only be efficient if teams are aware of other dependent teams around them and work towards eliminating overlaps.
- Successful teams are open about their work and heavily focus on building a “features-based pull” factor for their product vs. investing time in mandate-based push methods and governance around it.
- Letting current structures, ownerships, and territorial biases dictate the change in organizational transformation will only amplify delivery inefficiency.
In its most simplistic form, an organization has teams directly using the cloud with less or no governance. There are fewer dependencies amongst teams which results in execution speed and delivery. Developers, in this case, require minimal operational skills, and it is easy to get started and experiment. This pattern geared towards speed is not recommended as it does not scale beyond just a handful of accounts — lack of governance and process, in this case, introduces security risks and does not provide efficient methods to monitor spending.
In the early phases of cloud adoption, an organization needs to set up a “cloud platform” team responsible for simplifying consumption across other teams. This platform team is responsible for designing a scalable cloud accounts organizational structure with required security and a process to vend these accounts, accesses, and identities for other teams. This pattern provides good economies of scale and needs good planning; otherwise, it is prone to become a bottleneck via which other teams consume the cloud. I have seen in these teams the desire to build out a common path to production (or a pipeline) which can be extended and used by other teams to create cloud resources and deploy their applications. Depending on the organization’s size, often trying to build a single path with guardrails might be an extensive effort and a tall order. A standard pipeline also gets very opinionated and might not be quickly adopted by other teams who are as efficient in creating a similar alternative. An alternative, more flexible way to provide standard services and security would be to create landing zones with organizational guardrails and policies. Teams that consume cloud now have the autonomy to choose and build their CI/CD process, giving them excellent features throughput with lower friction.
Cloud introduces multi-tenancy and distributes people, processes, technology, and money across multiple groups from a centralized infrastructure team. In most cases, these groups are application developers who directly work with other teams to build services and products that support the business. As an organization transforms into a cloud-first enterprise, there will be shifts in the operational workflow process and how teams must structure themselves to execute efficiently. For a cloud platform team to be successful in a distributed ecosystem, it must carefully select cloud capabilities it will provide and govern and leave others for consumer teams to own. Two big product themes I have seen in being successful are self-service and autonomy. Providing user autonomy in cloud platform products results in lower adoption resistance.
Additionally, reducing the human touch factor and adding self-service enhances the experience and productivity. For example, creating cloud accounts with proper identity and authorization, security policies, tools, networking, and integration to logging can be a tedious process spanning multiple teams and techniques. This complex process can block product deployment for days. Automating this process and creating a self-service account vending process allows developer teams to accelerate their application deployment cycle.
“Cloud Management Platform” (CMP) allows teams to build and expose cloud services tailored for their enterprise, for example, a compute instance with a secure base image and applied policies available as a “service catalog” product. CMP allows cloud platform teams to become a “service broker” within the enterprise. Service catalogs are an excellent way to maintain governance but are not very scalable as consumer teams often require specialized services tailored for their application requirement. Maintaining a service catalog and being at par with speedy vendor feature release cycles is an uphill battle and involves much staffing. Further, these catalogs are not friendly to developers who prefer to execute “infrastructure as code” with their CI/CD process. A hybrid approach where consumer teams can self-service cloud services and the platform team provides security guardrails and monitoring is more sustainable in the long run.
As the number of consumer teams grows, the execution scale needs to be adjusted for the cloud platform team. Building smaller functional teams will provide focus and agility to meet the demand. Stream-based teams focussing on building foundational services and security can be one group. Cost management and Cloud FinOps another. Transformation programs and migrations can be a group working with application teams who deploy applications in the data center. Platform stream-based units to are supported by sub-system teams of product and project management.
As consumption of cloud becomes boring — the organization can use the platform model for other standard services and traverse up the stack to gain economies of scale. Some common examples are streaming and container platforms using Kafka and Kubernetes and data aggregation and storage services.
These topologies of teams can vary by organization, as culture, existing structures, people and skillsets, IT budget, metrics, and goals, amongst other factors, influence it. Building high-performing teams is a journey, and a longer one is of building multiples that work together well. Thinking long-term big-picture goals with clear short-term steps towards it goes a long way in achieving a set north star; it is a means to an end. As most things are, the perfect end keeps shifting; adapting a framework that can be easily changed and tweaked to meet changing needs goes a long way towards success.
Here is an example of a Cloud Platform team and streams within it. In the next article, we will look at what comprises each team — in terms of product, technology, people, and processes, and how they can efficiently interact towards scaling cloud and developer productivity across the enterprise.
Although majorly I write from experiences I have had working in the cloud space as a technologist, some of the ideas and concepts in this article are inspired by Scaled Agile & the excellent book on organizational design titled Team Topologies.
