Reflecting Your Organizational Structure
A successful cloud architecture relies on the overall design reflecting an optimal organizational structure. Getting this right from the beginning will deliver substantial benefits in terms of security, operational effectiveness and flexible growth. Even if you deploy just one application or system to the cloud, consider the topic of organizational structure.
The benefits of getting the design right include;
Security & Governance Ensuring only the right people can manage and administer appropriate resources. The protection of critical shared components and services. Separation of organizational entities within a tenancy.
Flexibility Allowing the optimal level of autonomy to organizational entities so that individualized objectives can be realized. Removing any over-reliance on shared services, thereby accelerating change.
Cost Management and Budgeting Making sure that organizational entities only pay for resources they use. Preventing unauthorized or unbudgeted deployment of resources and services Tracking expenditure over time and identifying trends.
We have seen in previous sections that the design of your tenancy, regions and compartments play a huge part in achieving your strategy. This section discusses identifying what approach might be most suitable for your organization and what capabilities and techniques can be leveraged.
Modernizing the Organization
We need to ensure that the current organizational structure is accurately represented. In addition, the time may be right for considering how the cloud enables organizations to think differently about how they are organized and structured. This can have advantages for the accelerated development of new initiatives and specialization. For example, in some circumstances, it is becoming increasingly common for organizations to move away from traditional layers of administration and support and introduce an organizational unit that encapsulates a discrete application/service or capability. This more “cloud-native” approach allows for accelerated development, less restricted technology choices, and less emphasis on shared services. A mix of these two worlds is likely to be the best approach.
Types of Organizational Hierarchies
In previous sections of this topic, we have seen that compartments, groups, and policies are essential to delivering the benefits outlined above. The question then becomes what combination of these will best mirror your organizational structure. There are two principal considerations when determining the answer to this question;
Model the IT Management Structure
Deploying workloads to OCI might result in an extension to your existing IT management structure, or it might mean addition to it.
Are the same teams going to manage the administration of OCI workloads and on-premises workloads, and will they be structured the same way?
Many organizations with a significant on-premises footprint have traditionally organized themselves around technology layers. Examples of these layers include;
- Security Administrators
- Network Administrators
- Storage Administrators
- System Administrators
- Virtualization Administrators
- Database Administrators
- Application Administrator
There are often further sub-categories within these roles depending on the type of application or environment that the team is responsible for. For example, there may be production database administrators and non-production database administrators. An application administrator may be responsible for configuring many applications, or they specialize in one specific application.
Whatever the combination of roles and responsibilities that already exist, it is essential to understand them, their scope, and whether it is appropriate to replicate this model for cloud-based deployments.
One of the significant benefits of the cloud is that it enables low-cost, specialized deployments of a complete technology stack to be delivered in minutes. Automation means that we can do this at scale, with low risk and minimal human intervention.
Therefore, the layered administration approach may not be the optimal administrative approach for these types of deployments. A more specialized, self-contained system of administration could be a better option. This enables the administrators to focus on delivering a specific functional service back to the business. The distinction between traditional administrative roles becomes blurred as team members are responsible for a more comprehensive range of technologies or even the whole stack.
Tip:
A key aspect of building an operationally efficient and secure OCI environment is having a complete understanding of how IT administration is currently executed. We should also establish what workloads might benefit from a change to a more cloud-native approach.
Model the Business Structure
When considering a multi-application migration to OCI, it can be advantageous to consider the existing IT management structure and the overall business structure.
We can justify this blended model simply from a security and administrative perspective. However, It can also enable future organizational flexibility, additional financial governance and expenditure tracking.
When we talk about modelling the business structure, we are primarily concerned with grouping applications together. Most business functions, such as; marketing, sales, billing, logistics, and service, have multiple supporting applications. Some may be shared, and others will be exclusive to the business function. By grouping them appropriately in OCI we can ensure that a consistent set of administrative policies exists for a given business function.
For example, a network administrator may manage the network that underpins sales applications but not the network that underpins logistics.
We could also extend these categorizations beyond business function and include different geographies, business units, or other organizational entities. In doing so, OCI can support an enterprise of any complexity, maintain administrative separation, and deliver insight into how cloud resources are used at each organizational level.
Example Organizational Structure
In this next section, we will look at an example of an organizational structure commonly encountered within OCI. This may or may not be directly applicable to your organization. We offer it here as a starting point for you to consider and help you draw out the optimal compartment structure for your organization.
Organized by Division, Environment, Application and Technology Tier
Level 1 The organizational structure depicted above shows the tenancy, or root compartment, at Level 1 in our compartment hierarchy. The root compartment will always be at Level 1 in every organizational structure.
We recommend that you not deploy any OCI resources in Level 1 (the root compartment) of your organizational structure.
Level 2 Level 2 represents a business unit, division, geography or other legal entity within your organization. The principal characteristic of Level 2 is that entities within it are entirely independent of each other.
Multiple entities (business units, divisions, geographies) can be deployed in Level 2. This can be done at the outset or gradually over time.
Level 3 Level 3 represents some form of environment type within the Level 2 entity. In the example, we have Innovation (sandbox), Non-Production and Production environments. At this level, we also have a shared environment that will house shared resources that deployments will utilize in the other environments.
Level 4 For our environment types, Level 4 represents each workload or application deployed to OCI. It could also represent a grouping of applications that perhaps deliver a specific business function.
For our shared environment, we have compartments dedicated to delivering specific capabilities to one or more of the workloads we deploy to OCI. For example, in the shared network compartment, we might have a Dynamic Gateway Router (DRG) used by several applications to access resources in each other’s networks. This is an example of how we begin to deploy a hub and spoke network.
Level 5 Level 5 represents the technology layers that make up the application. We have chosen to use Network, Database, and Application Tier at this level. There are usually dedicated teams that administer each of these technology layers. For example, we would usually not want the network admin for App1 to administer the database for App1.
Important:
For every branch of the compartment hierarchy, OCI resources should only be deployed at the lowest level. All parent compartments should be empty.
Hierarchy Design Tool
The diagram above illustrates the concept of the compartment hierarchy and how it can align with your organizational structure. The following diagram may be helpful as a tool to help you explore the design that works best for your organization.
