Hierarchy and Inheritance

Hierarchy

While we’ll cover policy management a little bit later, it’s important to understand policy management is centered around a principal of hierarchy. Specifically, a root organization is at the top of the hierarchy. Below it fall organizations, and then applications.

For many teams, the structure of organizations and applications will follow their own "command and control". In this instance, various business units are responsible for top level policies, and then they may add policies that are specific to their organization, or even to specific applications. As such, each business unit will have its own organization below the root organization, and those organizations will have unique applications below them.

For others, the applications their teams work on create more logical categories, such as "Internal". This allows a business to mimic commercial units where each business unit is a separate organization with applications below it.

For now though, the important pieces to remember are:

  • The root organization acts as a container for organizations.
  • Those organizations act as containers for applications.
  • The root organization has no applications attached to it.
  • Applications can only be attached to a single organization.

In the next section we’ll talk more about the flow through these various pieces, which we refer to as inheritance.

Inheritance

Every organization has rules around component usage. While we will discuss policy in much greater detail in the Policy Management chapter, for now, let’s just consider policy as a representation of all the rules and actions your business has to help identify which components your development teams should be using.

With rules as guidance, your teams will then simply follow that advice and go no further, or they might develop additional rules given very specific needs. Whatever the case, all teams are still accountable for a core set of rules.

Now, let’s think about how those move through our organization. We like to refer to this flow of rules, or policy, as inheritance. In general, whatever is specified for the root organization will extend out to all organizations. And, whatever is specified for an organization will extend out to any attached applications.

Of course there’s opportunity for additional customization here as well. However, the real advantage to inheritance is when you want to make changes that affect more than one organization or one application. For example, if you managed everything at the application level, one change needed for all applications would need to be made to each one. That’s not hard if you have ten applications, but what if you have a hundred, or thousands even? The same applies for organizations.

It is recommended that you use the root organization to set policy that applies globally to all organizations. You can fine tune policy at the organization level and allow your applications to inherit those changes.