The purpose of this section is to describe the role of a "Repository" in a development organization and how to implement a repository, using either a manual or automated approach.  

WHAT IS A REPOSITORY?

As should be obvious from studying the "PRIDE" methodologies, the cohesive bond behind all development efforts is the "IRM Repository" (aka, "IRM" or "Repository"), a system to inventory and control all of the resources in an enterprise needed to produce information. As developers progress through the "PRIDE" methodologies, information resources are defined and cross-referenced to other resources in the repository. In this way, the repository becomes a manifest of all information resources, thereby providing the means to share and re-use resources. The IRM is also a useful documentation tool; the various resource definitions should contain sufficient intelligence to generate reports, draw graphics (e.g., flowcharts), and interface with third-party development aids (e.g., DBMS, application generators, etc.).

The repository concept has been a part of "PRIDE" since its inception in 1971. Unlike classic data dictionary/directories that support CASE tools and DBMS packages, the "PRIDE" approach views a repository as a "bill-of-material processor" (BOMP) to catalog and cross-reference ALL information resources, not just those associated with the computer; a much more global perspective of an enterprise's information resources.  

RESOURCE DEFINITION

To implement a repository, it will be necessary to create the means to uniquely define each resource and link it to other resources. This can be implemented two ways:

1. Manually - using the resource worksheets accompanying "PRIDE".

2. Computer assisted - using commercial packages or to develop such software in-house. Today's Data Base Management Systems (DBMS) provide the necessary facilities to develop a computer assisted IRM, be it on the mainframe, mid-range, or PC level. To this end, the "PRIDE" resource worksheets provide a convenient template for creating such a repository.

In addition to control numbers and names, each resource should allow the inclusion of alternate identification fields for customers with other in-house numbering conventions.  

LOGICAL ATTRIBUTES

Although resource names may be used to identify redundant resource definitions, it is not necessarily the most reliable method for duplication identification. Instead, "PRIDE" recommends the "Logical Attribute" technique. Logical Attributes are a set of synonym words (pre-defined keywords governed by an administrator; normally consisting of nouns and adjectives) used to classify each resource. For example, consider how "Employee Number" and "Social Security Number" would be classified as data elements:

This means an effective repository should provide a flexible means to search for information resources; either by control number, name, or by Logical Attributes.  

RESOURCE RELATIONSHIPS

In addition to being able to identify and control each resource, a repository must be able to link and cross-reference resources in a meaningful way. This cross-reference capability alone is perhaps the most powerful aspect to a repository. A single resource may be used by hundreds of other resources. By maintaining these linkages, which can be extensive, a user can measure how the change of a single resource can effect other resources (e.g., an "Impact Analysis" showing resource relationships). For an example of "Impact Analysis," see:

• ISEM/Phase 1/Act A - Examples
• DBEM/Phase 1/Act A - Examples

INTERFACES TO DEVELOPMENT AIDS

Because of the vast corporate intelligence contained within it, the resource repository is the focal point of all development activities. Virtually all planning, design and programming aids will need to interface with it, as well as project management software. Because of this, the repository must have an "open architecture" allowing it to interface with a variety of tools. An "Import/Export Facility" is required to upload and download resource specifications to such things as CASE tools, program generators, data dictionaries, DBMS packages, word/text processors/editors, financial planning aids, graphics packages, Project Management systems, etc.  

BUILDING A REPOSITORY

When building a computer assisted IRM Repository, each Resource should be defined in terms of:

1. Identification - include control number (as mentioned above), name and, alternate identification (to accommodate in-house codes).

2. Logical Attributes - to uniquely identify each resource and detect duplicates.

3. Characteristics - describing the properties of the resource (see the "PRIDE" Resource Worksheets for specifics). Be sure to add validation rules and default values wherever possible.

4. Descriptive Text - to describe each resource and produce reports (interfaces to text editors/word processors are highly desirable).

5. Program Labels - primarily for data resources (DD, RD, FD, ID, OD). Remember, one data resource may have multiple program labels for different programming languages; e.g., "Customer Number" may be "CUST-NO" in COBOL, "cust_numb" in C, "CUST" in Assembler, etc.

6. Subordinate Relationships - linking subordinate resources to the resource. For example, an RD "Record" will have one or more subordinate DD "Data Definitions" subordinate to it.

7. "Where-Used" Relationships - showing where the resource is used by other resources. For example, an RD "Record" may be in the "Subordinate Relationship" set of an Input (ID), Output (OD), File (FD), or linked to other Records (RD).

The IRM Repository should be viewed as the hub of all development efforts and accessed by all development personnel, executives and managers, and support personnel. As such, consideration should be given to the Repository's access security, read/write privileges, file sharing, and backup/restore procedures.  

LOCATION

Since the intent of the repository is to promote sharing and re-using resources, it must be placed in a location accessible by anyone creating, updating or referencing information resources. This could potentially represent hundreds of people. The challenge becomes finding a centralized location that is convenient to everyone, without jeopardizing security.

If implemented manually, the "PRIDE" resource worksheets should be filed in numeric sequence in a filing cabinet. If automated, the repository can either be located on a mainframe and accessed through "dumb" terminals or on a file server accessible through networks.

The "PRIDE" vendor does not recommend maintaining multiple repositories on separate platforms. Although it is certainly feasible to set up such a configuration, keeping the repositories synchronized would be more trouble than it is worth.  

SUMMARY

Sharing and re-using resources is at the heart of a corporate-wide IRM strategy. In order to facilitate this, it is necessary to create a "repository" to uniquely identify, define and cross-reference ALL information resources, not just the computer or programming portions. Creating such a repository can be accomplished either manually (using the "PRIDE" resource worksheets), by purchasing a software product, or by creating such a mechanism internally. Regardless, the repository is vital to the successful implementation of the "PRIDE" methodologies and to Information Resource Management in general.

For more information on the resource worksheets, see: "PRIDE" Forms