Task: Configure Repository |
|
Purpose
Provide a governed asset management environment to preserve and improve the organization's software related investments. |
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| 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
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.
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.
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.
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.
|
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.
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.

|
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
More Information
Concepts |
|
Guidelines |
|
Tool Mentors |
|
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|