Azure Governance: Defining Your Organizational Hierarchy
A fundamental building block for your successful adoption of cloud services is the organizational hierarchy, a mode of organizing your cloud services, resources, and virtual machines in such a way that you ensure cloud governance and can better resolve billing within your organization.
Cloud governance is the answer to common questions like:
- “How do I keep my data compliant with industry regulations?”
- “How can I implement chargeback within my organization so I know which departments are consuming cloud services and account for that usage?”
- “How can I mandate security and access measures across our cloud environment?”
By implementing a flexible set of controls and overall organizational hierarchy within Azure, you can enable adoption of the cloud services your business units require and avoid shadow cloud use. A well-designed enterprise cloud environment can accommodate modern agile practices alongside traditional workloads.
Here’s how to structure your organizational hierarchy within Azure so you can set governance requirements and encourage speed of delivery for your individual departments and business units.
Aren’t hierarchies outdated?
With the introduction of Azure Management Groups, the previous model of departments and accounts became outmoded. However, creating a hierarchy as described below remains one of the best ways to initially structure your Management Groups.
Azure Management Groups allow a flexible structure of unified policies and access management across specified groups or business divisions. Each policy you apply to one group also applies to any nested underneath it. Each group has its own associated subscriptions.
What’s included in an Azure hierarchy
Your hierarchy will comprise subscription groups, subscriptions, and resource groups. We’ll be addressing the subdivisions assuming you have an Enterprise Agreement. Each subscription contains all resources while defining essential limits on the number of cores allowed, virtual networks, and more. Resource groups allow further subdivisions and groupings of those resources for better management.
You must arrange your hierarchy according to your individual organization’s needs and practices for billing and IT resource management. Generally speaking, the hierarchy moves from one to many in the following order:
Enterprise → Department(s) → Account(s) → Subscription(s) → Resource Group(s)
Each of these categories will correspond to a division of your business or organization depending on how you with to organize your hierarchy. For example, in a “Functional” pattern of distribution, it would be as follows:
Entire Organization (Enterprise) → Departments such as Finance, IT, Marketing → Account Owner within that Department (Account) → Individual Projects such as Dev Environment 1, Production Website, ERP App (Subscription)
Two other common patterns are “Business Division” and “Geographic”.
For geographic, the hierarchy is:
Entire Org (Enterprise) → Region such as North America, Colorado, or Midwest (Department) → Account Owner within that geo (Account) → Individual Projects (subscription)
Business division hierarchies are essentially the same as the functional pattern described above, but instead of the department being finance, marketing, or IT, it would be the entire business unit. For example, a technology hardware company might structure its Departments under Handheld Devices, Servers, PCs, Audio & Visual, etc.
Business division has become the most popular hierarchy, especially for large enterprises with many siloed divisions, as there are likely to be applications and services used by many different business departments within the same division.
Driving DevOps via hierarchies
One side effect of the Azure hierarchical model is somewhat forced adoption of DevOps practices. Namely, the development team may begin to take ownership of key governance, security, and billing implementations as they are the first to stand up a new service or resource group. Operational components like Key Vault management is often automated at the dev level before entering production as well.
This can seriously boost time to market as resource groups are streamlined and optimized. Eventually, your entire hierarchy benefits from automation and repeatable processes first established in a pre-production environment.