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.
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.
|