Best Practices for Administering the Harness Software Delivery Platform

This blog provides guidance on how best to organize Users, User-Groups, and Resources in the Harness Platform to efficiently organize your teams and achieve your goals of effective collaboration while minimizing organizational overhead. We base our recommendations on some of the key goals that you would like to achieve based on the kind of organizational structures you may have. This blog does not provide definitive instructions, rather a sample set of recommendations that should be modified to suit your organization’s needs.

Structure Matters

An organization’s structure can make it easy for people to work together and move faster. Or, it can make it harder for people to collaborate and get the desired results. So is true for applications and platforms – the provisions an application or a platform (we will use the word platform and application interchangeably in this context) provides to set up and organize users can help organizations be effective, or it can slow them down by adding complexity and administrative overheads. An application should allow customers to set up in a way that aligns with the organization's philosophy and reflect the guiding principles on how people work together. 

For the critical role that Harness plays in our customers’ software delivery lifecycle, it’s important that we allow our customers to be efficient. At the same time, we must make it easy for them to manage the platform. We realize that irrespective of how organizations are structured, they are likely to focus on one or more of the following goals:

1. Increase collaboration
2. Increase responsiveness
3. Minimize costs
4. Avoid duplication
5. Maintain oversight
6. Achieve compliance

Since there is no one-size-fits-all and different organizations are set up in a way that best helps them achieve their goals, Harness provides a flexible model that can be leveraged to create a structure that meets your needs. In this post, we will examine various ways in which organizations can set up Harness. Additionally, we’ll go over the Best Practices that will help them be more effective. 

Building Blocks

There are four main building blocks in the Harness platform. These can be used to set up in a way that best helps you meet your goals. 

Hierarchical Elements: Harness provides a hierarchical structure to organize users, resources, and projects. 

1. Project: At the lowest level, there are projects that can be used to group users together who work as a team on a project. All corresponding resources required for a project to exist independently can also be created in the project, or can be inherited from the parent.
2. Organization: An organization in Harness represents a logical entity for organizing multiple projects together. This helps create a separation of duties and isolation of resources. Organizations are an effective way to represent multiple BUs or product lines. Organizations are also an effective way to set up a newly-acquired business without impacting existing entities.
3. Account: An account is the top-level entity or a root node in Harness. Users created at account-level are either meant for managing administrative functions or providing oversight over all organizations and projects. Resources created at account-level can be used in all organizations and projects. 

Resource Groups: Resource groups are a very effective way of grouping resources that need to be managed together as a unit. Resource groups can contain all resources of all types, or all resources of a specific type (e.g., all secret managers) or named resources (e.g., secret manager X1 and cloud provider Y1). This provides great flexibility in grouping resources and controlling permissions for ease of management and for creating clear separation of duties. 

User Groups: User groups are an easy way to group together users who are working on same projects and have similar roles. User groups are a convenient way to manage permissions and notification preferences for users who have similar responsibilities.

Roles: A role is a set of permissions that allow or deny the ability to perform operations on resources. When a role is assigned to a user or a user-group and is then applied to a resource group, it allows users to perform operations as defined in role on set of resources as grouped together in the resource group.

The following diagram shows a conceptual view of how users are grouped together to form user-groups, which in turn are given roles that apply to a resource group at different scopes.

Recommendations

Using the building blocks described above, customers can create a structure that suits their needs, from creating a totally open and flat structure, to a completely granular structure with defined boundaries - and everything in between. Let’s look at some of the key factors that influence the decision of how Harness should be structured, and corresponding recommendations. We will use the following factors as key decision-making criteria to suggest the most optimal structure.

1. Size of the organization
2. Type of org structure 
3. Centralized
4. Decentralized
5. Number of business units / product lines
6. Key goals that an organization would like to achieve

Below are some of the representative structures and the corresponding recommendations based on key goals organizations would like to achieve.

Setup 1: Small-Sized Organizations With One Product Line

Based on the assumption that key goals that such an organization would like to achieve are high collaboration with shared responsibilities, Harness recommends the following:

Setup: Single organization with multiple projects.

Resources: All resources are created at account level and only very limited resources are created at project level.

Users/User-Groups: All users and user groups are created at account level with permissions provided across all projects as per their roles.

Setup 2: Medium-Sized Organizations With Multiple Product Lines

As the scale grows, focus shifts on effectively managing resources while continuing to hone in on collaboration and speed. If the focus is on managing resources centrally while decentralizing execution, then Harness recommends the following:

Setup: One organization for each product line or BU.

Resources: All resources are created at account level and only very specific resources are created at org or project level.

Users/User-Groups: Admin users (or users who need to manage resources) are created at account level. Users who need to maintain oversight or enforce governance are given appropriate permissions in the entire account or within an org. Rest of the users are only granted permissions  in the projects they are required to work on.

Setup 3: Large-Sized Organizations With Multiple Business Units 

Large organizations usually have multiple BUs, where each BU is responsible for their own P&L. This requires them to manage their own resources separately. At times, the nature of business is also such that it prevents resources from being shared across BUs. If the focus is on having decentralized management of resources along with decentralized execution, then Harness recommends the following:

Setup: One organization for each product line or BU and for every newly acquired entity.

Resources: Resources are not created at account level. Resources that are common across projects in an organization are created at org level and rest are created at project level.

Users/User-Groups: Admin users are created at account level. Users who need to maintain oversight or enforce governance are given appropriate permissions in the entire account or within an org. Rest of the users are only granted permissions  in the projects they are required to work on.

Summary

Depending on how your organization is set up and what key goals you would like to achieve, there are different options that you can use to set up the Harness Software Delivery Platform. These options will help you get the desired results in an effective and efficient way. 

Would you like to keep reading technical pieces? We have a couple for you right here: Service Accounts: A Path to CI/CD Automation and Event-Driven Architecture Using Redis Streams. If you missed my first piece on User & Role Management in the Harness Software Delivery Platform, read it today!

-Kapil