Considerations in Role Design

The connected world of business today requires that people perform various tasks culminating in a desired goal while having different responsibilities. The level of complexity creates problems for anyone managing access to various systems. Roles, being a collection of permissions to be assigned to users, are being used to manage the complexity.

Design of roles is fast becoming a subject of interest in both the academic and corporate world for obvious reasons. Every organization attempts to perform its own exercise, due to the fact that they all have different functional needs and structures. The attempt is made mainly as a bottom-up or top-down exercise. It must be understood that role design is not an activity; it is a process which keeps evolving. The changes can occur due to corporate restructuring or business demands.

In both cases, the roles can be structured in multi-level hierarchies to represent business and technical capabilities. These levels can depend on the complexity of the existing system and the number of functionalities that needs to be assigned; the bigger the size of the business, the greater the number of roles and levels.

For companies opting for a top-down approach, the goal is to achieve simplicity at the highest level so that roles can represent functional responsibilities, which are grouped together for a certain position. This approach normally starts with the business defining the functional needs. The experts of particular business area provide the input in mostly non-technical terms, focusing on various functions that have to be performed to achieve business goals. This, in many cases, results in more access requirements than the real need. The culture also impacts the input as many functional areas would not like to lose their existing capabilities, even when they do not need them. There is also a possibility of missing some of the functionalities, resulting in a distorted picture of access rights. These business functionalities are then translated into technical roles and then specific permissions.

For the companies opting for a bottom-up approach, the exercise begins by collecting existing permissions in various systems and then performing mining operations to ascertain the current level of access. This collection is then used to identify commonalities, which in turn are used to define technical roles and then the business roles. As this approach is based on “what is”, this can sometimes ignore the real need and uses the current state as the appropriate level of access. As in the case of top-down approach, the culture plays an important part in defining the roles.

A combination of both these approaches may be a better strategy, where the business defines its needs and functionalities, which are compared against the collected access information. This will result in identification of commonalities in access rights, while providing a foundation for defining appropriate technical roles.

As the process is evolved thru various reviews, we can arrive at a stage where a defined business role would result in highly structured set of permissions.

It is important to note that not all permissions can be part of individual roles, as any attempt to do that may result in explosion of roles, hence defeating the goal of simplification. While defining roles, one should always look for commonalities. If the differences appear between the need and the permissions in the set of roles, the individual specialized permissions may be left outside of the roles.