Task: Specify Repository Community
Define the major sections of the repository, how many repositories there may be, and the teams and content in each repository.
Disciplines: Asset Governance
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs
      Main Description

      The enterprise needs to determine whether there will be one asset repository or many asset repositories. In addition, for each asset repository, the organization of the assets, the teams, and the review processes, needs to be determined.

      In this task the focus is on determining how the teams will access the assets in the repository, what sub-groups of the repository will exist, and which assets will go into which sub-group, or rather Community.

      One deterrent to reuse for consumers is being presented with too many assets to evaluate. Decomposing the repository into Communities helps you mitigate some of this issue.

      A Community is an arbitrary collection of users, roles, and their assets. A Community may be defined along several boundaries, including:

      • Organizational unit
      • Project
      • Users with a common role, such as Business Analyst.

      In the following image the Business Analyst Community is organized according to role, the Project XYZ Community is organized according to a project, and the Testing Team Community is organized according to organizational unit.

      An example of a Community organization.

      The Community becomes the primary element for organizing the repository. An asset lives in one Community. Roles and permissions are specified for a Community. Review processes and other workflows are specified for Community.

      Using the Reuse Strategy and Reuse Assessment, evaluate the target audience, consumers, and participants in the asset program as input to what Communities to create. A user may participate in many Communities.

      There are some tradeoffs to consider when creating Communities. If you create too few Communities then the scope may be too broad, leaving the user to navigate many assets. If you specify too many Communities then the administration costs can become too burdensome for specifying access control rights, review processes, asset types, and so on for each Community.

      A rule of thumb to follow is to create a Community for each unique set of assets over which you want specific control and governance over. That control may be needed by a manager, or by a business unit, or by a customer. So, if your enterprise sees value in providing a place for business analyst assets and controlling the access to and the review and approval process of those assets, then it may be valuable to the enterprise to manage a Community for business analysts.

      An administrator needs to be determined for each Community. The administrator will specify the roles, permissions, review processes, and so forth.

      It will take several iterations to create the proper set of Communities. In most cases, the repository will need to be configured, and then exercised for some time in order to properly refine it. It is best to start with fewer Communities, and then add more as necessary.

      With a repository organized into sub-groups and Communities, and with roles and permissions specified, now the administrator maps the users.

      A user may participate in many roles. The user information will likely need to come from a directory system such as LDAP.

      Steps
      Specify Communities
      Create one or more Communities considering the guidance above.
      Specify Roles for Communities

      A user may have many roles. A role is typically created for the repository when an identifiable set of artifacts and assets for that role can be described. When considering creating a role, evaluate the asset types in the repository and any Asset Type Specifications. This can both discover potential asset types as well are refine what assets and artifacts the role will be working with.

      The role definitions should be coordinated with appropriate stakeholders and governance boards. It is valuable to understand other roles that are being proposed for the repository, as you may be able to reduce the number of role names when finding similar and common roles in other Communities.

      Specify Permissions for Roles in Each Community

      The administrator setting these permissions needs to understand the roles and potential users of a particular set of assets. In general, the enterprise should control access to the intellectual property, and the artifacts that represent the investment of the enterprise.

      The permissions for a specific role may be scoped to assets of a particular asset type, to assets with particular classifications, or to a particular asset owner.

      For example, the administrator may state that for the Business Analyst role in the Service Analysis Community, they may work only with assets of type "Business Process" which are classified for "Financial Services" systems.

      Illustrations
      Examples
      Key Considerations