Task: Configure Repository
Plan and execute steps to administer the repository in order to be used.
Disciplines: Asset-Based Development
Purpose
Provide a governed asset management environment to preserve and improve the organization's software related investments.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
  • None
Optional:
    Outputs
      Main Description

      There is several major administration roles involved with configuring an asset repository. The steps for configuring the repository cross these roles. These roles may be played by a single person, but that is not very likely. For more information see: Role Roadmap. The major roles are:

      • Community Administrator: this role is responsible for specifying the asset types, review processes, roles and access control, and review processes for a specific Community. A Community is an arbitrary collection of users and the assets that are relevant to them.
      • Repository Administrator: this role is responsible for specifying server paths, application server paths, database configurations, web service locations, background process settings, and overall performance.
      • Integration Administrator: this role is responsible for integrating the Repository with development lifecycle tools such as SCM tools, change management tools, and service registries.
      Steps
      Create Category Schema

      There may be many category schemas typically in a Repository. A category schema is developed to represent a certain perspective. For example, we can take an asset such as a stock quote service. We can determine the asset type is Service, and we may classify the stock quote service as a "non-commercial" service, and as a "domestic" service, providing quotes for only domestic traded stocks. The values for classifying the service in this example may come from the same category schema, or it may come from multiple category schemas.

      Creating a category schema often requires visualization and socialization. You need to see the schema and achieve some buy in from stakeholders. The stakeholders involved typically include managers, administrators, as well as Asset Consumers and Asset Producers. The Asset Consumers are the key stakeholder as they will use the values from the schemas to search assets.

      However, the Asset Producers should also be involved if possible with buy in as they need to understand the meaning of the category schema, and its various branches, as they will use these values to classify the asset.

      To visualize the category schema you may use a model, such as a UML model (shown below), or you may use a nested tree view, as shown further below.

      Sample Insurance Category Schema Model

      A UML model of a category schema.

      Sample Insurance Category Schema (Text Format)

      • Financial Reporting
        • Stockholders equity
        • Financial position
        • Income statement
      • Health Insurance
        • Public
          • Claims processing
          • Tax
          • Social Security
        • Private
          • Mandatory
          • Employment group
          • Community-rated
          • Risk-rated

      Once the category schemas have been agreed upon, it is loaded by the repository or Community Administrator into the Repository. It is beneficial if the administrator can control when the category schema is made visible to the Repository users.

      Category schema versions present another level of issues to address. If a category schema is loaded and visible and the next version of the category schema is loaded, you need to consider how to apply changes to the schema into the assets in the Repository. Key considerations include: removing a value from the schema, or changing the name of the schema.

      Specify Asset Types

      An enterprise typically has assets which are first-class citizens in the software development process, such as designs, code, and tests. There is generally a description of the artifacts and assets an enterprise uses to develop software. An asset is of a particular type. For example, an asset called "Credit Report Service" could be of an asset type called "Service". There can be many service assets in the repository, each structured according to the asset type "Service". The Administrator can use a picture describing the type of assets and the nature of their relationships, such as the one below. The model states that the asset type Business Process has an association with the asset type Service Interface, and so forth.

      Type of assets and the nature of their relationships in an organization.

      The Repository is configured to support and enforce asset types and their relationships as well as their content and possible category schemas. For each asset type specify the following:

      Name Asset type name
      Description Description of the asset type
      Artifacts For each artifact specify the following: Artifact Name, Artifact Type, Cardinality
      Relationships Relationships to other asset types; specify the nature of the relationship and the cardinality of the relationship
      Category Schema Specify which, if nay, category schemas should be used with assets of this type
      Custom Meta Data Identify additional meta data elements that are needed for assets of this type

      For example, to specify the Service Interface asset type it may look like the following:

      Name Service Interface
      Description The interface to a service
      Artifacts

      Artifact Name: Interface   Artifact Type: WSDL   Cardinality: 1

      Artifact Name: Message Definition   Artifact Type: XSD   Cardinality: 0...*

      Artifact Name: Interface Model   Artifact Type: UML Model   Cardinality: 1

      Artifact Name: Service Description   Artifact Type: DOC   Cardinality: 1

      Relationships Optional: Business Process   Required: Service Implementation Required: Service Test Suite Optional: Service Design
      Category Schema Schema: Insurance
      Custom Meta Data Required: Support Contact


      Specify Communities and Access Control

      Organizing the Repository into partitions of assets that are for specific users and interests enhances the scalability and approachability of the repository. Making all assets visible to everyone quickly decreases the value proposition of the repository as it becomes too large for people to navigate.

      A Community provides an arbitrary collection of users and assets. An asset is managed by one Community.

      A critical part of governance for asset management is to control access to the proper set of assets. There are several significant roles for asset-based development. These roles have primary interaction with the Repository through key scenarios. The roles which primarily interact with the Repository are shown in the image below.

      The roles which primarily interact with the Repository.

      These Repository roles have core permissions associated with them. In general an Asset Owner can create, update, and delete assets they own. Whereas an Asset Review can search, browse, and submit assets, but generally won't be able to delete an asset.

      The Repository roles should be mapped to the roles of the software development process. The kinds of assets and the type of work performed with the assets varies as you combine these Repository roles with roles from the software development lifecycle.

      The Architect performs the roles of Asset Producer, Asset Owner, Asset Consumer, Asset Review, and Review Board member.

      In the image above, the Architect will perform the activities of the Repository roles of Asset Producer, Asset Owner, Asset Consumer, Asset Review, and Review Board member and will have the permissions specified by the Repository Roles. The mixing of these roles also identifies the kinds of tools and user interfaces the Architect will use to complete the work.

      In this example when the Architect is authenticated with the Repository (s)he will be able to conduct operations on the Repository that are a union of the Repository role permissions, within the Communities to which the Architect has been granted.

      Union of the Repository role permissions, within the Community Space(s) to which the Architect has been granted.


      Specify Review Processes

      A critical part of a governed asset management system is to organize and execute reviews of assets before they are generally available. In principle the content to be admitted into the visibility of Asset Consumers should be material which has been evaluated and approved. There are degrees of formality in this of course and good judgment should always prevail.

      The administrator specifies the review processes for a given Community. This means that for each Community there may be one or more review processes. A review process specifies several key items including:

      Name Review process name
      Description Description of the review process
      Conditions The asset type(s) to be included in the process. The categorizations the assets should have.
      Review Board Indicate if a review board should be used, and if so, who the members of the review board are
      Reviewers Who should review the asset, either by name or by role

      The Administrator may use this Community Map as a starting point.

      There may be several levels of governing bodies to oversee the process of approving assets for reuse. At the simplest form the assets may be automatically approved as soon as they are submitted to the repository. For certain asset types this may be reasonable. The next level of review may include reviewers that are identified. Based upon their submitted reviews and the votes they cast the asset may be approved or it may rejected.

      There is another level of control, which is to use a Review Board. In this case the reviewers submit their reviews and cast their votes. Then the Review Board evaluates the submitted reviews and casts the official vote to accept or reject the asset.

      A general review process without using a Review Board may look something like the image below.

      A general review process without using a Review Board may look something like this image.

      So if you specify a review process in the Repository, such as the one shown below, then when an asset is submitted it may look like the image further below.

      Community Claims Processing Community
      Name Service asset review
      Description Review process for service assets
      Conditions Asset type = Service
      Review Board Not enabled
      Reviewers John Doe, Jane Doe


      The sample flow may be as shown below.

      A sample review flow which includes the users and their responsibilities at each step.
      Configure Repository Users
      The users are mapped to the roles in the Community. The users may come from existing directory services such as LDAP.
      Configure Repository Integrations
      A Repository may integrate with various tools such as SCM tools, change management tools, service registries, and so forth. The Integration Administrator integrates these tools with the Repository to provide a seamless interaction for the software development workflows.
      Configure System Timers and Notifications
      The Repository generally has system notifications and timers where it performs its work in the background. The Repository may create search indexes on a regular basis or it may provide notifications to subscribers of events have occurred on the assets. The Repository needs to be configured to provide a balance of optimal performance and timely updates.
      Illustrations
      Examples
      More Information