REPOSITORY FEATURES

The repository acts as an encyclopaedia of knowledge about the organisation and its goals, structure, functions and processes. Conceptual data models and process models should be stored in the repository, as well as information about design details and the different types of data and data structures in use across the enterprise.

The scope of a repository is shown in Figure 10.4. The repository should be capable of dealing with the definition of multiple object types with differing properties and complex relationships. It should provide facilities to handle multiple names for objects in a controlled manner. It should support such things as database design and code generation. It should be possible to partition the repository to represent different views of information, corresponding to different stages in the software development life cycle. It should be possible to maintain effective version control.

FIGURE 10.4 The scope of a repository

The repository should have an easy-to-use query language, should have compare and merge facilities, should be able to represent information in graphical format and should be able to generate formal documents. It should be able to import and export information to and from other products, such as CASE tools.

A repository should be perceived as a database of information. The procurement of a repository should follow the procedure for the procurement of any software, as outlined in Figure 10.5. Good design is essential if the user requirements are to be satisfied. Ideally, therefore, we should discipline ourselves to produce a suitable conceptual model based on an analysis of the requirements. This will provide a blueprint for the repository that we can use to evaluate the available products.

When evaluating repositories it is important to look at the functionality and flexibility of the products available. The following questions are a small sample of those that should be asked:

FIGURE 10.5 The repository procurement process

• What properties can be defined for each object type?

• How does the repository deal with multiple names?

• Is it possible to support multiple views or versions?

• Is it possible to tailor the information model?

• Are there any performance implications in doing so?

• Does the repository support different types of database management systems?

• What types of relationship are supported?

• What types of query can the repository answer?

• Is the query language easy to use?

• How does the repository import or export information?

• What standard reports are offered?

• Can report layouts and terminology be tailored?

• How easy is the product to install and maintain?

• How easy is the product to use?

• Is it menu-driven? Does it have online help facilities?

• What features for maintaining integrity and security are there?

The data management staff should not only have authority to select and manage a repository but should also be part of the evaluation process for other systems development software tools in order to ensure correct links can be provided with the repository and that the principles of data management can be upheld.