Holacracy and Identity and Access Management

As IAM-consultants we are experienced in designing access models, and we are used to a typical environment where access is derived from an employee’s department, position and role. A person only needs access if and for as long that access is relevant in relation to his or her position in the organization and the tasks assigned. If there is no need for access, all authorizations should be revoked. This access models are unique to every organisation yet require some form of framework to base them on. Like roles, hierarchy, and organizational structures. Holacracy, more specifically IAM and holacracy, poses a new challenge in that regard.

At two of our recent customers we ran into a new ‘experience’. When we discussed how to design the access model we found out that these organizations applied a holocratic way of working. That requires some explanation of the concept of Holacracy. You may wonder what that is and so did we. We know about holistic philosophy: that is about everything. We know about hierarchical organization types and matrix organizations, that’s all about organization. And holocracy is trying to combine these two: everything about an organization. But still it is not that easy to define.

Holacracy. What is that?

Holocracy is a management framework, beyond hierarchical management, that is based on maximum self management of and by employees. Decision making is decentralized and teams are self-organizing, to an extreme level. It goes beyond agile ways of working in that sense.

As Identity and Access Management experts at SonicBee we are currently facing the challenge of managing access in this non-hierarchical, non-matrix-like, non-agile way of working at two customers.

In general you can say that people get their authorizations based on different characteristics, such as their place in the organization (department), their position and role, their physical location and several other of this type of ‘attributes’. The main structure usually is the top-down hierarchy. In contrast in holocracy there is no hierarchical structure, so it’s less obvious to find persons accountable for access, and besides, teams and roles within teams constantly change. This makes IAM and holacracy a tough combination to crack.

Holocracy is ‘the next way of organizing’. We used to have strict hierarchical organizations with a central and top-down management of work. The past years we’ve also seen a more agile way of working develop, with more autonomy in teams and less central and top-down direction. Holocracy takes this even further: there is no central and there is no top-down, the organization works in teams and these teams define the work themselves.

For us as IAM-experts we now lack the comfortable environment of departments, functions and roles. Then how to define why someone gets access or not?

Access based on roles – the traditional way of RBAC

Traditionally we design a model where access is granted to employees through the concept of roles. These roles are a bundle of individual authorizations. So for example: a customer service representative may need access to 8 applications. Instead of one-by-one granting these authorizations, which takes time, it is easier to bundle these 8 authorizations in one role. It is even more easy then to decide up front: every customer service rep will get this role. In this way we don’t need to decide for every individual employee that he or she is a customer service rep, but we create a line of code that says: if an employee has the job function of customer service rep, then automatically give this role, which effectively will give that employee the 8 applications. Now that is what we call efficiency (and we also label it ‘role based access’ or RBAC).

Automating that workflow of employees joining and leaving the company, or moving internally, is no rocket science. Getting an identity feed from an HR-system with all changes and performing some magic to create or delete accounts is what the so-called Identity Governance and Administration software suites do. And after managing the accounts, adding authorizations is a little more complex, we add ‘roles’ (groups of authorizations) to the identities: A manager can define the authorizations of a direct report, the manager grants and revokes authorizations, the manager receives reports and recertifications. The manager is accountable for the tasks the employee performs.

Holacracy: Roles without hierarchy

But not so in holacratic organizations. Holocractic organizations have teams, they call ‘circles’. And there is no hierarchical organization, there are only circles. And within circles there can be even more circles. People work in one or more circles. And the challenge is that there are no managers in the traditional sense. Each circle has governance in some kind of self-organized way of working. A circle has a specific goal and the people working in the circle define their governance to reach the goal.

Within circles ‘roles’ are assigned to people, but these roles can vary in time, in context. There is no set relation between hierarchical, RBAC-roles and Holacratic roles. In fact, in a holacracy even those roles may vary in time.

Holacracy and RBAC? Does that work?

In regular hierarchical RBAC, a person gets a business role and that business role connects to roles in applications and platforms, the so-called application roles. These application roles in turn give more fine grained access, the effective authorizations, or entitlements. This role creation process is not simple, It is so complex, that once a role is created, it cannot change easily. In fact I would invite any organization to celebrate the creation of any role!

This complexity as a consequence means that roles are static. And that creates some difficulty in holacratic circles: self-governance implies that when authorizations in roles can vary, the traditional RBAC-method doesn’t fit easily.

In dynamic, holacratic role management the roles are not static. Meaning that for IAM and holacracy, assigned roles can result in different effective authorizations. The role that was granted yesterday, can have different meaning today. So the employee still has the same role (that of the customer service rep), but today there are 9 applications part of that role, and yesterday there were only 8. This puts a lot of emphasis on proper role management, and otherwise the access might change over time, without anyone really being in control of that.

Access Governance

From the perspective of authorization management, this means that in a holacratic organization, access governance must be implemented differently. Managing roles and authorizations requires a dynamic view on authorizations. And for Role Based Access Control it means that dynamic role management is essential and that version control and monitoring of role assignement is a key requirement.

In regular Identity Governance and Administration solutions the hierarchical view on governance is part of the features. Therefore traditional IGA solutions do not fit well in non-hierarchical environments.

In a future blog we will explain how we try to solve these issues for our customers and we will show that being in control may not require a hierarchy after all.