Skip to content

People, roles and organizations

The nature of organizations

Everyone plays multiple roles in their lives: parent, daughter, employee, scout leader, … even within an organization it is not uncommon, particularly for more experienced people, to be assigned to multiple roles.

For example, figure 1 shows some of the roles that Tessa Tube performs at Coco Pharmaceuticals. Researcher is her primary role, but she is also a manager, system owner and information consumer. Each of these roles needs particular skills and knowledge. They will also take up some of her time.

Figure 1

Figure 1: Roles that Tessa Tube plays in Coco Pharmaceuticals

A role has a context. For example, Tessa is a manager, but not for everyone in Coco Pharmaceuticals. She is a manager of a specific team. Similarly, she may be a system owner, but not of all systems.

So a role has a scope, and roles can be combined together to form the complete “job” that an individual performs.

Now consider what a role is from an organization's perspective. Roles can be thought of as slots, or vacancies, in the organization's teams that individuals are appointed to for a span of time. A role can have more than one person appointed. Head count is an optional attribute that indicates how many people are expected to be assigned to the role.

The teams are typically organized into one or more hierarchies. These hierarchies reflect how the work has been divided up to meet the objectives of the organization. Figure 2 shows the general structure.

Figure 2

Figure 2: Basic structure of an organization showing the top-level organization linked to the top-level teams. Nested under the top-level teams are the sub-teams. The roles in each team are divided into leaders and members. The roles can have multiple people appointed to them.

Figure 3 shows part of the Coco Pharmaceuticals organization.

Figure 3

Figure 3: Coco Pharmaceuticals divides its labs and research work from the sales and manufacturing. The leader of the labs is one of the founders, Terri Daring. Tessa Tube works for her and Callie Quartile works for Tessa.

Coco Pharmaceuticals is a small company but even so, its organization structure is hard to draw on a flat diagram. Terri Daring is a founder and a member of the Founders team (not shown in figure 3) as well as being a leader of the Labs organization.

Projects and communities

An individual acquires their roles from the projects they work on and the communities they belong to as well as their direct team in the organization hierarchy (department).

Figure 4 shows a role attached to a community. The CommunityMembership relationship defined the type of members that perform the role. So a community may have a community leader role that is separate from the community administrator role for example.

Figure 4

Figure 4: Linking of a role to a community showing the type of membership associated with the role

Figure 5 shows the roles associated with a project. There are the roles associated with the management of the project as well as the project team that performs the work of the project.

Figure 5

Figure 5: Linking of roles to a project. There is a separation of the roles to manage the project from the team who does the work.

Types of roles

Egeria's open metadata types represent a role using the PersonRole entity type. Figure 6 shows a hierarchy of subtypes for 'PersonRole' that are also included in the open metadata types to help structure your organization's role types into broad groups that identify particular skill sets. For example, Coco Pharmaceuticals may define role types of Researcher and Data Scientist that inherit from PersonRole; a role type of DepartmentManager that inherits from TeamLeader; and a role type of ClinicalTrialLeader that inherits from ProjectLeader.

Figure 6

Figure 6: Inheriting from PersonRole (from model 0112) are the team roles (from model 0115) of TeamMember and TeamLeader; the ProjectLeader role (from model 0130); the CommunityMember role (from model 0140) and the GovernanceRole roles (from model 0445) of Governance Officer, Asset Owner, SubjectAreaOwner ComponentOwner and DataItemOwner.

Instances of a role type (ie role instances) describe a specific role in the organization that has a scope and potentially people appointed to it. For example, in figure 7, an instance of the ClinicalTrialLeader role has been created for the Drop Foot Clinical Trial project. Tessa Tube has been appointed to that role to indicate that she is the leader of that project.

Figure 7

Figure 7: The left-hand side of the diagram shows the inheritance hierarchy of the type for ClinicalTrialLeader which inherits from ProjectLeader which inherits from PersonRole. The right hand-side shows the instances: the Person entity for Tessa Tube is linked to the ClinicalTrialLeader entity for the Drop Foot Clinical Trial which in turn is linked to the Project entity for the Drop Foot clinical trial project.

Roles in action

Roles are a key mechanism for organizing people for governance. Consider this scenario.

Clinical trial example

The characters in figure 8 are involved in the clinical trial for a new cancer drug developed by Coco Pharmaceuticals. They are collaborating on their findings as selected patients are given the new drug. The data is created by the hospital and shared with Coco Pharmaceuticals for analysis. Results and feedback are returned to the hospital personnel.

Figure 8

Figure 8: The people from the hospital (Grant Able, Angela Cummings, Julie Stitched and Robbie Records) and from Coco Pharmaceuticals (Callie Quartile, Tanya Tidie and Tessa Tube) who are working together on the clinical trial.

In this example, there is an exchange of sensitive personal data which needs to managed carefully, both for legal reasons and to maintain the trusted partnership between the hospital and Coco Pharmaceuticals.

When it comes to working with data, the role each are playing is often related to the task an individual is performing and the data resources they are working with. This becomes important in managing the access that an individual has to the resources.

Clear responsibilities

Figure 9 shows how the roles - and hence the responsibilities - or individuals vary with respect to the patient data.

The hospital has a close association with the information subjects (patients) and information originators (medical staff) who are typically the information owners.

The hospital appoints an information steward (Robbie Records) to work with the information owners on the terms and conditions that must be met by external organizations using the data. Robbie also chases down data quality issues and ensures their data practices are clean.

At Coco Pharmaceuticals, Tanya Tidie is appointed as the information custodian for the data. She takes responsibility for meeting the terms and conditions for the incoming data.

Figure 9

Figure 7: Robbie Records and Tanya Tidie managing the sharing of data from the hospital

Figure 10 shows a broader view the roles of each character when it comes to the transfer of data from the hospital. The role names are not important. There is little standardization fo these names in the industry. Just focus on the fact that the people involved with the clinical data have different roles/responsibilities with respect to its protection and use.

Figure 10

Figure 10: The patient is the information subject. The information originators are the medical staff making notes and capturing clinical data. Robbie is the information steward managing the data and its transfer to external organization on the hospital-side. Tanya Tidie is the receiver of the data and as the information custodian, she is responsible for the proper management of Coco Pharmaceutical's copy of the data. Tessa Tube and Callie Quartile are information consumers. They read the data and perform analysis on it to determine how well the new drug is helping the patient.

Tanya Tidie needs to ensure that only the clinical trials team have access to the data. The team also need to be educated on their responsibilities to meet the terms and conditions of the data transfer.

Actor Profiles

Figures 2, 3 and 7 show that individuals are represented using a Person instance. Figures 2 and 3 also show Team instances for each team. Both Person and Team are types of ActorProfile (see model 0110). ITProfile is another type of ActorProfile that are linked to Assets to show the user information typically of a process such as a connector or a software server.

Figure 11 shows the different types of actor profile as well as a link to a UserIdentity entity. This describes a user account or userId associated with the profile.

Figure 11

Figure 11: There are three subtypes for ActorProfile: ITProfile for assets, Person for individuals and Team for organized groups of roles. Any one of these subtypes can have a UserIdentity associated with them.

Unless security is disabled, every action performed in an IT system is associated with a user account. The linkage of the UserIdentity which represents the user account with the profile males it possible to look up the originator of the action.

User accounts are typically associated with specific running processes and individuals. However it is also possible to have a shared user account for a team, although this makes it difficult to identify which person performed a specific action.

It is also possible for an individual, team or process to have multiple user accounts

Figure 12 also shows that a profile can be linked to multiple user identities but not the other way around so that given a userId it is possible to look up the profile.

Figure 12

Figure 12: Showing the possibility of a profile having multiple user identities associated with it

Figure 13 show that the other elements linked to the profile creates a broader view of the context of an action in the IT systems.

Figure 13

Figure 13: The full context of a user action

Linking governance and security to roles

Access to resources is controlled by identifying which user accounts can access which resources. Typically similar resources are identified and a user group is defined for them. The group contains the list of user accounts that are allowed to access the resources.

The roles, teams, projects and communities in an organization help to determine who should have access to specific resources. The user identities identify the user accounts of the individuals and processes associated with the work that is required. Egeria also provides the means to defined the security information that links between the organization and the asset descriptions of the resources.

SecurityGroups are entities that describe a user group in a security control system. They are subtypes of the GovernanceDefinition that supports two relationships:

  • GovernedBy - to indicate the resources that are governed by the governance definition. When the governance definition is a security group it means these are the resources that are protected by the security group.

  • ScopedBy - to indicate where the governance definition applies. For a security group this means the people, roles, teams etch that should be given permission to the security group.

Figure 14 shows these two relationships.

Figure 14

Figure 14: Security groups are subtypes of governance definitions. They can be linked to resources with the GovernanceBy relationship to show that the security group is used to govern access to these resources. The security group can also be linked to an organization, service or business capability using the ScopedBy relationship to show that it is only used within the identified scope.

Figures 15 and 16 show some examples of the security group linking different types of resources to the different parts of the organization.

Figure 15

Figure 15: Example of associating a security group to a governance zone to give a process that is maintaining the resources in a governance zone.

Figure 16

Figure 16: Example of associating a security group to a team to give the team members access to the team resources.

The navigation between these elements is technically feasible, but time-consuming and difficult to audit. Egeria also defines a classification for a user identity that lists all of the security groups that should be assigned to a specific user identity.

Figure 17

Figure 17: The SecurityGroupMembership classification lists the security groups that the user identity should be added to.

Egeria's governance actions can automate the maintenance of the SecurityGroupMembership classification

Egeria's synchronization capability helps in the maintenance of the organization data and user identities in open metadata followed by the synchronization of the security information in the security access control services:

  • When onboarding a new service that has an embedded security system (such as a cloud platform) or even for Egeria itself.
  • When making changes to the organization structure.
  • When setting up new projects and communities.

Using organization data with open metadata

Egeria may have one or more of the following uses of organization data and this will effect the scope and coverage of this data that flows through Egeria.

  • Egeria is a consumer of the organization data for collaboration and governance.
  • Egeria is a validator of the consistency of the organization data in the different systems.
  • Egeria is a distributor of the organization data between systems. This may include its only security definitions used to security the access of open metadata through Egeria.

In general, if Egeria is just consuming the organization data then it only needs information about the people and teams using Egeria. If, however, Egeria is validating or distributing organization data, it tends to hold all of the organization data that is relevant to the sources and consumers of the organization data.

The text below covers all three uses.

Systems that hold organization data

Organization data is widely distributed across an organization's systems. Each system holds a different subset of the organization data and is updating some or all of its content. When planning to integrate organization data into Egeria, it is important to understand where the authoritative source of each attribute is located and how the information in different systems can be correlated together. Below are the descriptions of three systems in Coco Pharmaceuticals that are responsible for managing organization information.

HR Information Manager (HRIM)

HRIM is owned by the Human Resources (HR) team in Coco Pharmaceuticals for managing information about employees. It covers applicants, current employees and those who have left.

Figure 8

This is a model of the HRIM data. You can see it includes not only the employees, but also the department structure.

Figure 9

The cocopages company directory

The cocopages application provides contact information for anyone associated with Coco Pharmaceuticals business. This includes contractors and business partners such as the hospital staff working on clinical trials. It is also owned by the Human Resources (HR) team in Coco Pharmaceuticals but any Coco employee can update their own entry and add third parties to it.

Figure 10

This is a model of the cocopages data. You can see it covers email addresses and telephone numbers.

Figure 11

Security Administration (SecAdmin)

SecAdmin is owned by the security team in Coco Pharmaceuticals. It defines who has access to which resources.

Figure 12

This is a model of the SecAdmin data.

Figure 13

Figure 14

Automating the exchange of information

Figure 15

Using information about individuals in collaboration

Collaboration metadata

Contribution records

Karma points and karma point plateaus


Back to top