So You Want a Repository

All Rights Reserved. No part of this publication may be reproduced in any way without prior written permission.

INTRODUCTION

Have you notice how the way we construct applications is changing? Automation is finally hitting our own profession. Computer Aided Software Engineering (CASE) tools are being evaluated, piloted or used in nearly every major development organization. Gone are the days of hand-drawn (and often hand lettered) requirements and design models. Now they are developed and maintained on PCs that also provide crisp laser printed documentation. Screen dialogue prototyping provides interactive requirements acquisition and application design capabilities that interface with mainframe code generators.

Most definitely, the cobbler's kids are finally wearing the latest in designer footwear. And the shoestring that keeps these tennies tied together and functional is a central, integrated database of information required to develop and manage software constructed in the CASE environment.

At the same time, enterprises in government and industry are recognizing that information is an important business asset that must be managed and developed as any other business resource. In many, the need to manage the data that describes the business information is being emphasized. There is a great deal of overlap in the data that an enterprise needs to manage its information asset and the data that information engineers require to develop applications in a CASE environment.

Suddenly, Data Administration (DA) finds that it is responsible for one of the most databases in the enterprise. The lowly Data Dictionary has evolved from a data element documentation tool to the Information Repository, the knowledgebase of information that assists information specialists in their efforts to document and manage the enterprises's information asset and the portfolio of applications that has been configured to support that asset. This same repository serves as the heart of the Application Enabling Environment (ADE) which is the foundation of the enterprise's suite of CASE tools.

It has fallen to the Data Administrators to develop the requirements for managing the enterprise's information resource within a CASE environment, decipher the evolving Repository standards, evaluate the available products and select the Information Repository product that best meets their organization's needs. Hopefully, this article will help our fellow DA's analysis process by providing some criteria that can be used in evaluating Information Repository products.

As in any situation where the environment is evolving and in flux, the vocabulary used to describe and discuss the information repository tends to be ill defined and/or defined inconsistently. Being first and foremost good DAs, we find this situation somewhat intolerable. Therefore, for the purpose of this article we will use the following definition of terms:

• Information Repository (IR):

• Information Repository Directory System (IRDS):

• Repository:

An enterprise's Business Information Resource (BIR) consists of two parts:

• the business information that the enterprise maintains
• a description of that information in the form of a set of facts describing all of the persons, places, things or concepts that the enterprise must know about in order to compete effectively in its chosen industries and/or to complete its mission.

Many enterprises have information systems that are currently operating, are in development or are planned to be developed to manage the information asset. This set of information systems is commonly known as the enterprise's Application Portfolio (AP).

The Business Information Resource and Application Portfolio are described in terms of components that we will refer to as Data Objects. These data objects, the relationships among them and the facts that must be known about them are an important part of the Information Asset. The information about these data objects must be maintained, secured and distributed to the appropriate parties in ways that are similar to the maintenance, security, and distribution of business information.

An Information Repository serves as the source of information to be used by:

• people to understand the meanings, relationships among, and proper uses of the data objects.
• automated tools used to specify and develop information systems.
• applications, in real time, to access and manipulate the enterprise's data.

The people, automated tools and applications that access the information repository are referred to as "Users".

The purpose of this article is to offer criteria to be used as the basis for evaluating a Repository. The series of questions provided below is intended to help determine the scope and quality of the functions and data structures supported by the system being considered, and the degree to which it adheres to evolving industry standards (e.g. OMG Metadata Object Framework).

In preparing this article, we have assumed that the reader is familiar with basic information repository concepts, and we have limited the criteria to repository functions only. We recognize that many vendors provide or will provide additional tools which are designed to use the information repository such as data structure generators, graphic model generators, code and data structure decomposition and analysis support, and so on.

We have not included criteria for evaluating these types of tools, although their availability will surely be a serious consideration when choosing a repository. Although it is an important component of the Application Development Environment, the repository is only one such component.

This article is not intended to be a set of guidelines that will determine with certainty whether a given repository can perform to your satisfaction. We have only attempted to addresses those criteria necessary to determine if a product warrants further in-house evaluation within the constraints of your current ADE.

Intended Use

Each evaluation criterion is presented as a question or checklist. These criteria can be easily tailored to fit the evaluator's objectives. Not all of the questions found in the document may be needed at any one time.

REPOSITORY EVALUATION CRITERIA

Supported Usage Modes

There are three modes in which a Repository can be used within an enterprise:

1. Is the Repository passive?

2. Is the Repository active in development?

3. Is the Repository active in production?

A number of IRDS standards have been proposed by various standards group:

• Object Management Group's Meta-data Object Framework Specification
• Meta-data Coalition's Meta-data Interface Specification
• CASE Data Interface Format

In addition, Microsoft is developing its own repository product. Given the influence that Microsoft products tend to have on the marketplace, its repository architecture can also be considered to be a de facto standard.

The discussion of what these standards entail, how they differ and the current status of the proposals is a topic best saved for another article. However, it is important that the evaluator of an IRDS product be aware of these standards and, if possible, come to a conclusion as to which standard best fits the needs of his/her enterprise.

1. Which IRDS standards does the IR conform to:

• OMG MOF
• Meta-data Coalition MDIS
• CDIF
• Microsoft
• Other

The Data Object Model is the basis of the structures that are supported in the IR. Normally, the Data Object Model is discussed in terms of an Entity-Relationship Diagram (ERD). This is the conceptual view of the actual structures supported by the IR database. To adequately evaluate the Data Object Model support features of an IR, it is important to develop your own model of the data objects your enterprise has identified as needed to support its information resource.

A Data Object Model includes:

• Business Rules, Information Resource and Application Portfolio Data Objects
• The relationships that exist among those data objects
• Facts that describe and define the data objects and relationships

The IR's Data Object Model is specified in terms of:

• Meta-Entities
• Meta-Relationships
• Meta-Attributes
• Meta-Datatypes
• Procedures to enforce your meta-data management business rules

The Data Object Model corresponds, in concept, to what is commonly referred to as a Meta-Model.

A Data Object Instance is a single information resource or application portfolio component defined to the IR as a Data Object. For example, if the enterprise must have information about a Customer to conduct business, then Customer is a component of the information resource. Customer is defined to the IR as an Entity, which is a data object, and therefore becomes a data object instance in the IR.

1. Does the IR support a Data Object Model?
2. Has the IR Developer provided a Data Object Model as a starting point for using their IR?
3. How well does the IR Vendor supplied Data Object Model meet your requirements, as specified in your enterprise's Data Object Model?
4. How well do the data objects map (e.g. entities, relationships, attributes, files, data elements, screens, reports, programs, applications)?
5. How well do the facts maintained about the data objects map (e.g. name, description, date created, business examples, allowed values)?
6. How well do the relationships defined among data objects map (e.g. Table to Data Element, Data Element to Attribute, Attribute to Entity, Program to Table, Business Process to Program)?
7. How well do the facts maintained about data object relationships map (e.g. cardinality (minimum and maximum), optionality, identification)?
8. Can you modify the definition of the Data Object Model that the IR provides?

If so, are there any constraints on the degree to which you can modify the supplied Data Object Model?

9. Can you add new data objects, relationships and facts to the developer provided Data Object Model?
10. Can you delete data objects, relationships and facts from the developer provided Data Object Model?

Data integrity concerns the accuracy and validity of data stored in the IR. The following criteria can be used to ensure that the IR provides an adequate level of data validity and integrity checking. It is important to understand that the allowed values of "facts", allowed relationships among facts, etc., which are often referred to as "domain" considerations" are an important part of the Data Object Model, and should be controllable like any of the parts of that model.

1. Does the IR support enough data types to accurately define the facts you have identified to define the data objects and their relationships? The minimum data types that should be supported are:

a. Numeric (Integer or Real)

b. Alphanumeric

c. Alphabetic

d. Text

e. Date

2. Is it possible to indicate the minimum and maximum length of a fact?
3. Is there an upper limit on the maximim length of a fact based on data type?
4. For numeric fields, are decimals allowed?

If so, is there an upper limit on the number of decimal places allowed?

5. What are the date formats supported?
6. Can default values be set for use in data object creation?
7. Does the IR provide support for integrity as defined by E. F. Codd's Rules for a Relational Data Base Management system, such as:

a. Domain Integrity:

1) Ranges

2) Data Type

3) Uniqueness

4) Inter-fact dependencies

 

b. Entity Integrity:

1) on Insertion

2) on Replacement

3) on Deletion

 

c. Referential Integrity (IRD Rule Support):

1) Set Null

2) Restrict

3) Cascade

8. What processing occurs when a validation or integrity rule is violated?
9. How is the user informed that an error has occurred?
10. What error correction facilities are provided at error detection time?
11. Does the IR enforce the defined rules for data validation, integrity, security, standards, etc. for enterprise defined data objects, relationships and facts to the full extent that it enforces these rules for the developer provided counterparts? For transactions submitted in batch mode, as well as those processed in real-time?
12. Is the IR based on an industry proven database management system? Is this a relational DBMS?

An important objective of information resource management is to eliminate redundancy and to ensure that data object instances are named properly. Most enterprises have naming standards for how data object instances are named and the abbreviations to be applied to those names. The ability to enforce the enterprise's naming standards is an important consideration in choosing an information repository.

Just as it is important to ensure that the contents of the data base are valid and accurate, it is important to ensure the data base is not physically destroyed. Criteria to make that determination noted in this section:

1. Is the IR able to recover from an abnormal situation, leaving the database in tact?
2. Is there sufficient logging to provide roll-back and replay recovery?
3. Does the IR provide an automatic recovery facility, that restores the data base to its current state even if the physical media upon which the data base is stored is destroyed?
4. Does the IR alleviate the need for the user to make frequent back up copies of the data base for recovery purposes?
5. If the data base is destroyed or corrupted, does the IR provide for automatic recovery of the data base without the need to reenter transactions which have occurred since the last back-up of the data base was made?

This section concerns data security (sometimes referred to as data privacy). In any case, this section addresses the confidentiality and protection of information within the data base. The criteria recognizes the need of more than passwords for IR data and function access.

1. Does the IR provide the ability to restrict access to only authorized individuals by:

The ability to place data object instances under change control so that the impact of modifications to existing definitions can be closely monitored is another important feature of an IR.

1. Does the IR provide a mechanism to place data object instances under change control?
2. Is change control placed at the data object instance level or at the fact level?
3. How does the IR maintain an audit of changes made to data object instances?
4. What information is maintained for change audit purposes?
5. Does the IR allow the enterprise to tailor the change audit facility?
6. How does the IR's change management facility interface with the version control facility?
7. Does the IR provide a facility that assesses the potential impact of a given change on the other data object instances related to or dependent upon the data object instance being changed?
8. How far down the relationship/dependency network does the impact analysis facility navigate?
9. Is it possible to tailor the degree to which the relationship/dependency network is navigated on a given impact analysis request?
10. Is it possible to indicate within the IR the business party that is responsible for approving a change request if a data object instance for which they are responsible is impacted by the change?
11. If so, is there a mechanism for notifying that business party of the change request?
12. To what degree can the IR implement a change automatically, once approved, and propagate that change through all of the impacted data object instances?
13. Can the IR automatically invoke the automated tools that generate data structures, code, models, documents, test scripts, etc. to implement the effect of a change in the applications portfolio?
14. Can the IR back-out any change implemented in error and restore everything to its prior state?

An Application is always complete, but never finished. The need to develop evolutionary applications which are architected for flexibility and change is obvious.

Maintenance is the process of implementing changes and enhancements throughout the life of an application. Version control is a set of procedures and techniques that allow multiple incarnations of the same data object instance to exist simultaneously as the business evolves over time.

There are two levels to version control: Data Object Instance and Release.

An Data object Instance is an identifiable constituent of a business model or application. Examples include Entity, Business Function, Program, Database, Table, Data Element and Test Case. A Data Object Instance is documented as a Repository Object.

A Release is an identifiable packaging of related Data Object Instances that has been or is intended to be implemented as a unit. The changes to business models and applications can be managed through releases. Multiple releases of the same model/application may be in development and in production at the same time.

Version Control is concerned with the ability to modify data in the IR database without impacting the integrity of the relationships with the users of that data. Version control occurs at two levels:

• data object model
• data object instance

Data Object Model version control deals with the ability to evolve the definition and structure of the enterprise's Data Object Model while providing support for data object instances defined under prior incarnations of the model. It is the option of each IR user to decide if and when conversion to a new Data Object Model version occurs.

Data Object Instance version controls deals with the ability to evolve the definition of and relationships between the enterprise's business information resource and application portfolio data object instances while providing support for those applications that were developed using the prior definitions and relationships. Each application must have the option of if and when to convert to the new version of the data object instance.

Release Management is used to identify a package of data object instances that are intended to be treated as a unit. Release version control is nothing new to application developers. Techniques have been implemented in most environments which allow a release to be based upon prior releases, but which can evolve independently of the prior releases. Repository release management is an extension to these application concepts.

Releases build upon one another, where each release represents the delta from its parent release, starting with the current approved business model or production version of an application. Each release represents a snapshot of the data object instances at a specific point in time. A set of dependent releases is referred to as a "release stack".

1. Does the IR provide release management?
2. Can the dependencies between releases be defined to the IR?
3. Can the IR user specify which release modifications are to be made to?
4. When a data object instance is requested, does the IR retrieve the specific data object instance version appropriate for the release being used?
5. If updates are made to a data object instance is a new version automatically created? Is the new version designated as a component of the release being used?
6. Does the IR provide facilities to conduct impact analysis across related releases?
7. Can the life cycle phase of the release be designated (e.g. business rule analysis, requirements identification, design, code, testing, production staging)?
8. Does the IR allow multiple release stacks to co-exist?
9. Does the IR provide the ability to perform impact analysis across release stacks?
10. Does the IR provide facilities to compare release stacks?
11. Does the IR provide facilities to compare releases? Merge releases?

One of the most important features of an IR is its ability to provide data object instance information for analysis purposes. A full compliment of relational and text oriented selection capabilities must be provided. In addition, complex comparative abilities are needed to identify possible data redundancies or deficiencies.

1. Is a standard or compatible SQL language supported?
2. Does the IR provide an open architecture that can be incorporated into a distributed platform using standard approaches (e.g. ODBC, DCOM, CORBA)?
3. Can the user extract reports and/or the replies to ad-hoc queries using simple, non-procedural, English-like statements?
4. Does the query system provide a wide range of selection mechanisms?
5. Can the query system select information based on a match of key or field contents?
6. Can the query system select information based on a match of partial key, or field contents using "wild-card" or "match-one" characters?
7. Can the query system select information based on a match of field contents using column position values?
8. Can the query system select information based on a field's contents being equal to Null?
9. Can the query system select information based on a match of key or field contents against a class or range of values?
10. Can the query system select information based on a match of key or field contents against calculated values?
11. Can the query system select information based on a match of field, or key contents against conditional values resulting from a nested query?
12. Can the query system select information based on a wide range of relational operators: EQ, LT, GT, NE?
13. Can the query system select information based on any combination of the above selection criteria using Boolean operators AND, OR and NOT?
14. Where multiple relationships exist between data object instances, does the IR provide a mechanism for designating to which relationship the query applies?
15. Can the query system provide summary information about the data object instances selected, such as counts, sums, averages, percentages, totals, etc.?
16. Can the user pre-define queries and/or reports and invoke them by simple entering the name of the query or report?
17. Can the user use previously defined queries or partial queries as building blocks in new queries and/or report requests?
18. Does the query system enable control breaks to be defined for any output field or any combination?
19. Can the user designate multiple control breaks for a report?
20. Can the query system provide fast output in a different sequence in which the output would have been otherwise?
21. Can the query system enable calculations to be performed on the output during the output process (e.g., to provide the answer to "what if" questions?
22. Does the query system furnish an easy-to-use mechanism for automatically substituting commonly used terminology in place of actual information values stored in the data base (e.g., Male, Female, Accounting, blue, etc. are displayed instead of M, F, Actg, 01)?
23. Does the query system enable output to be routed to any combination of windows, paper or magnetic media?
24. Can the output format be designated with regard to titles, page and column headings, vertical and horizontal page dimensions, margins, column widths, etc?
25. Can the output of the query system be used directly as input to other applications and automated tools?
26. Can the results of multiple queries be compared using standard set manipulation language (intersection, union, subtraction, etc.?
27. Can the results of the query be presented graphically (e.g. object relationship model, decomposition diagram)

A complete GUI management system that serves as the on-line front-end to the IR is essential. Such a facility should be easy enough for a novice to use, providing visually satisfying forms that are workflow oriented.

1. Does the IR provide an on-line front-end access facility?
2. Does the front-end conform to industry GUI standards?
3. Can the facts displayed on the window be protected from input?
4. Is fact validation done at the client level? Server level? Both?
5. Are the user security constraints enforced at the GUI level?
6. Does the IR provide a fully functional word processor and/or text editor for text fields with word-wrap, insert, delete and block management capabilities?
7. Can the enterprise select an industry standard word processor/text editor as an alternative to the one provided with the IR?
8. Does the enterprise have control over how the facts are displayed to the user? Can windows be customized by the enterprise?
9. Is a wide range of display widgets available such as: colors, drop-down boxes, hierarchy trees, radio buttons, etc? Are these characteristics under the enterprise's control?
10. If a new data object, relationship and/or fact are defined, is the associated window dialogue to manage them automatically generated?
11. Does the GUI facility enable easy definition and use of "help panels" for the end user?
12. Can the contents of the help panels be modified by the enterprise?

To be most effective at managing and disseminating meta-data across the enterprise, the IRDS needs to be web-enabled. Deployment of business models and associated documentation over the enterprise's Intranet can be a valuable approach for reviewing and approving meta-data.

1. Does the IRDS provide facilities for posting meta-data to the web?
2. Are the generated web pages compatible with your organization's standard web browser?
3. Can the graphical representations of queries be displayed as clickable image maps?
4. Does the IRDS automatically generate hyperlinks between the data object instances?
5. Are all the maintenance capabilities provided through the web?
6. Does the IRDS provide discussion threads and feedback capabilities?

One of the requisites in a workstation environment is the need to support multiple concurrent users. This requirement implies a networking configuration capability for data sharing in the DBMS. Therefore, the IR must have those mechanisms in place to handle concurrent processing.

In addition, these users may be accessing the IR from different computer and terminal types. The need to support multiple platforms is very real.

1. Can the IR run on all of the computer architectures that your enterprise supports?
2. Can the IR's database and functions be distributed across multiple computers and platforms?
3. Can the IR be accessed from multiple platforms in real-time? through batch import/export facilities?
4. Is there a limit on the number of concurrent users that the IR can support?
5. How does the IR ensure against concurrent updates of the same data object instances?
6. Does the IR provide a check-out facility to users who will be doing analysis off-line for a period of time?

Performance is concerned with speed with which the IR responds to user requests placed against it, and the efficiency with which data can be stored.

1. Does the IR provide automatic data compressions for string fields? For binary fields? For date fields? For time fields?
2. Does the IR capacity limitations meet your enterprise's expectations in terms of volumes, response times and throughput requirements, e.g., database size, number of transactions per second/minute etc?

The Information Repository is central to the Application Development Environment, but is not its only component. Other tools, e.g. systems analysis and decomposition tools, modeling tools, compilers, source code library managers (if not part of the IR) and source code scanners/parsers must also be available.

1. How rich a set of tools is part of the IR?
2. Are these the tools you need?
3. How well does the IR work with tools supplied by the same and other vendors?
4. How good are relationships between the IR vendor and other vendors who offer supporting tools, or with which there must be cooperation as new versions of the tools and the IR are released?

When we evaluate any vendor's IR, we must evaluate the vendor' support capabilities too. There are no "bug free" products on the market! So we must be assured the vendor will be there tomorrow as he is today.

1. Has the manufacturer of the IR proven his "survivability" by having been in business for several years?
2. Is there a Service and Maintenance contract available?
3. Is there IR support obtainable locally?
4. Are training classes and workshops for the IR available on a regular basis?
5. Are there toll-free numbers to obtain technical consultation with number of call limitations?
6. Is there a trial period policy available of sufficient time length to evaluate the IR?
7. Is onsite technical consultation provided by senior vendor technical representatives?
8. Is the vendor willing to provide a list of current customers to discuss their level of product satisfaction?
9. Is there a "user group" with which you can meet to resolve issues, share software and common solutions, etc.?