Dots of Tech Perception

For the purpose of role definition, two strategies can be used: top-down and bottom-up. The top-down strategy for role definition means essentially breaking down an organizational system to gain insight into its compositional business units. Each department is then refined in detail, sometimes in more than two additional levels (i.e. groups, teams), until the entire specification is reduced to business roles. A bottom-up approach for role definition is piecing together entitlements objects in order to define technical roles. In a bottom-up approach the individual entitlements are first specified in great detail. The entitlements are then linked together to form technical roles, which in turn are linked at a number of levels depending on the desired granularity, until a complete top-level system is formed.

In conclusion, bottom up role definition focuses on analyzing the entitlements in target systems and is typically performed by a technical team, while the top-down strategy is centered on user attributes and is performed by a business team. Regardless of the approach, the enterprise should first capture the scope for of role definition, and then decide on the strategy to use. Two main objects are prevalent when defining roles: defining roles for administrative purposes and defining roles for security and compliance purposes. First, when the goal of role definition effort is to validate and verify the technical environment and to correct inaccurate functional and security controls, then a bottom-up strategy is recommended. This strategy starts with collecting and analyzing entitlements. The roles resulting when implementing a bottom-up strategy can be both technical roles and business roles. In order for the resulted roles to become usable they need perspective from business users and owners. Second, when the main objective of role definition is to provide validate and verify the administrative environment and to correct inaccurate structural controls, then a top-down approach is recommended. This strategy focuses on creating business roles based on analyzing job responsibilities as well as the relationship among responsibilities. However in order for these roles to become usable they need perspective and input from resource owners.

This differentiation allows the two strategies to be implemented independently during the role definition process. Up to a certain point, the two strategies can be applied in parallel. They should meet in the middle to create a mapping structure between the business roles and technical roles. Technical teams can make considerable progress toward creating a role structure for an enterprise, but the roles must ultimately be approved by business owners. Similarly, business representatives are able to create high-level role definitions but will have some difficulty in mapping these roles to the entitlement infrastructure.

After the strategy (bottom up, top down or a combination of both) for role definition is established based on the project scope, the process scope must be established. The role definition process depends on what needs to be done in order to define roles and to some extent how it should be done (e.g., establishing some role guidelines, a quality model for role definition). Both top-down and bottom-up strategies can be tactically implemented using processes like role engineering and role mining. If the role definition process scope is to enumerate the set of roles without cardinality constraints, the process tries to answer the question “how many roles?” and not “why so many roles?” In this case, the outcome of the definition effort will be represented as actions to be taken on the entitlements and users for which data is being or has been collected. This process applies best to organizations with a small number of employees, or with highly specialized business units with a small number of users. However, if the process of role definition aims to correct or improve user attributes and entitlement data and/or the workflow of the administrative tasks in the future, then cardinality constraints must be taken into consideration and the question that is important here is “Why so many roles?” In this case, the outcome of the definition effort will be actions to be performed on the process that produced the data. Therefore, the focus of the process will be on data cleaning, data consolidation and data synchronization.

The role definition process can be viewed by extrapolation as requirements analysis. Coyne was the first one to use the term role engineering (Coyne, 1996). Requirements analysis methods can be regarded as process-oriented, data-oriented and control-oriented (Thayer & Dorfman, 1997). From the point of view of role definition, a process-oriented method would take into consideration the way the systems transform user and entitlement data into roles, with less emphasis on user and entitlement data itself, and also with less emphasis on control aspects. Data-oriented methods for role definition would emphasize the state of the provisioning system as a user and entitlement data structure. Control-oriented methods would emphasize synchronization, exclusion, concurrence, and role activation and deactivation. In conclusion, all three methods mentioned in this paragraph can be used in the activities performed at different stages in a role definition effort. Careful consideration should be given to each phase scope, and an appropriate engineering method should be selected.
Requirements engineering activities associated with role definition may be classified in terms of:

• role elicitation: discovering, reviewing, and understanding roles and constraints
• role analysis: defining role structure and constraints
• role specification: refining and documenting roles structure and constraints, clearly and precisely
• role verification: ensuring that the roles are complete, correct, consistent, and clean

Data mining is the use of automated data analysis techniques to uncover previously undetected relationships among data items. Data mining often involves the analysis of data
stored in a data warehouse. So, by extrapolation, role mining can be defined as the use of automated data analysis techniques to uncover previously undetected relationships among users and entitlements. Role mining involves the analysis of user information (attributes and entitlements) stored in various systems. Data mining techniques can be used to perform entitlement-to-technical-role associations. In the same way, user attributes to business role can be discovered using pattern recognition techniques. But the final entitlement-to-technical-role and business-role-to-user attributes definition decisions can only be done in a business centric process. Data mining activities associated with role definition may be structured in terms of:

• role data collection
• role data preparation
• role modeling
• role evaluation

Data mining for role definition is nothing more than a tool that can assist the role definition process.  But this approach can reduce the problem space to either solve the problem or reduce the problem enough so that one can find the optimum solution with a (worst-case) exponential method.  However, it is very difficult to use data mining approaches to mine for roles in an industrial environment. The main reason is that they fail to discover roles with semantic meanings. Existing role mining problem definitions only use user entitlement information. Since entitlements are symbols without meanings, this limits the ability to identify usable roles. Mining on both user attributes and entitlements might be a future research direction to consider.