1 Rules in Information Management
 

Business rules relating to the management of information as both a business necessity and as data in a data store have been successfully used by the British Army. This paper defines the principles of rule usage that underpin this work.
 

Rules in information management have three main areas of application:

• Business perspectives on Information
• Conceptual data store requirement definition.
• Integrating business Information with data in data stores

2 Business perspectives on Information
 

It has always been notoriously difficult ensuring that the best use is made of information. Within an organisation information flows in all directions; up and down between levels of management and across different business domains. Each business domain at each management level has its own perspective on information and these domains need to be free to describe information in their own terms. The multiple perspectives and uses of business information are shown schematically in figure 1.
 

Figure 1: Multiple perspectives and uses of business information
 

Best use of information involves the integration of these different perspectives while preserving the autonomy of the different business domains to be free to describe and use information that best satisfies their requirements.
 

To achieve the integration of information while maintaining business domain autonomy four components are required:

• An Information Definition Language, IDL, that has explicit rules to ensure a precise, unambiguous and complete definition of information.
• Rules to present an IDL model in a number of different forms while maintaining consistency
• Rules to define the congruent elements in different information perspectives
• Rules to integrate the different perspectives of information progressively into a single enterprise wide perspective

2.1 Information Definition Language (IDL)
 

The IDL operates at three levels:
 

All IDL rules are applied at the integration and enterprise wide levels but a limited number of IDL rules are relaxed at the business level. This is to ensure that the gathering of business information perspectives is not inhibited by the IDL. Whenever IDL rules are applied they are applied with full rigour.
 

Note: The author knows of only one such IDL - the Corporate Business Modelling Language (CBML) developed by the British Army, which is the one he has used in this work.
 

2.2 IDL model presentation
 

The presentation of a model applies to all three levels and may take a number of different forms. It is important that however a model is presented the representation is consistent and complete within the parameters of the presentation.
 

The common forms of presentation are:

• Graphical: apart from the rules to ensure the precise IDL syntax is maintained, graphical representationis not rule driven.
• Verbal: verbalisation is rule driven to ensure that, although it is grammatically correct prose, the content is precise and complete.
• Exchange standard such as XML: this is rule driven ensuring that content is precise and complete.

2.3 Defining congruent elements in different information perspectives
 

Congruent elements are IDL elements that represent the same thing, or information about a thing, in the real world but are different elements because different business domains describe the thing, or information about a thing, differently.
 

If the IDL models are well formed the changes between the different levels should be a simple matching of IDL elements.
 

2.4 Evolving and integrating the different perspectives of information
 

The integration of information while maintaining business domain autonomy is achieved by evolving the business level IDL models to an integration IDL model which in turn may be combined with other integration IDL models to develop the single enterprise level model. Where IDL elements are reconciled to other IDL elements this is recorded. The evolution is shown schematically Figure 2.
 

Figure 2 The integration of information while maintaining business domain autonomy
 

The three levels of IDL model are shown in figure 2 as three concentric ellipses representing the business level models, the integration level models, and in the centre the single enterprise wide model.
 

The double headed arrows linking the three concentric ellipses in figure 2 show the reconciliation of an element in one IDL model to an element in another.
 

A similar reconciliation, although not shown in figure 2, may take place between elements in IDL models at the same level. The evolution of business level model to an integration level model:

• It is crucial that a business domain is free to define their information in their own way but this cannot be guaranteed to meet the standards needed for the sharing of information.
• Once a business level model has been developed it is manually evolved into an integration level model but rules exist to define the changes that are permissible.
• The process of generating an integration level model from a business level model acts as a powerful validation process of the business model and changes to the business level model cannot be ruled out.
• The inter-relationships of the IDL elements will change between the business level and the integration level as the element associations evolve from a narrower business perspective to the wider perspective needed for integration.
• Different business domain models may use the same IDL element. When the same item of information is defined differently in different business domain models then these are declared to be congruent and this is recorded to facilitate the ultimate sharing of information.

The evolution of an integration level model to a single enterprise wide model:

• Once an integration level model has been developed it is manually evolved into a single enterprise wide model.
• The concept is that there should be no reason to change the integration level model but the classification concepts may need to be extended as the scope of the single enterprise wide model is much less restricted..
• The inter-relationship structure of the model elements should not change between the integration level and the single enterprise wide model..
• The same IDL element may be used in the single enterprise wide model as is used in one or more business domain models. When the same item of information is defined differently between the single enterprise wide model and the business domain models then these are declared to be congruent and this is recorded to facilitate the ultimate sharing of information.

3 Conceptual data store requirement definition
 

The precision of the IDL model is such that the information may be used to define a conceptual data structure for holding the information as data within a data store.
 

The basic concept is to define the conceptual data structures required to meet the information needs of a business domain. The structures would be driven by the integration and the enterprise wide level models but the business level models may be used to define input/output objects. This is shown schematically in figure 3
 

Figure 3 Generating conceptual structures data and objects
 

The conceptual data structures would not inhibit information system developers from building systems to their own standards but would ensure the actual information held in the implemented data structures is sharable across the enterprise.
 

The reconciliation between the logical data structures and IDL information models will be such that the accuracy of any implementation can be demonstrated.
 

To facilitate full sharing of information the logical to physical mappings will be required but the rules required will be less complex than the rules for existing data in extant data stores.
 

The logical structures, driven by rules, will be in the form required by the developers for example:

• UML
• Entity Relationship structures.
• XML schemas

Special constructs are needed if the full richness of IDL is to be represented in the logical structures for example to distinguish between IDL’s specialisation and categorisation.
 

Structure rules are required for each of the target platforms to define the structures within IDL that are not in the target if there is to be no loss of information about information.
 

There will also be rules for the automatic generation of the required logical structures in the language of the target platform taking full cognisance of the structure rules.
 

The reconciliation between IDL and the logical structures in the language of the target platform will be recorded.
 

The rules for XML are dependent upon the XML schema of the target.
 
 

4 Integrating business information with data in data stores
 

The physical instantiation of business information is the data held in data stores. These multiple perspectives are shown schematically in figure 4.
 

Figure 4 Multiple perspectives of business information from implemented data structures
 

The structure of the data within a data store is a particular information perspective. This information perspective relates to the data in the data store and not to the information perspective of a business domain. Even when a data store is associated with a specific business domain the data structures of the data store are unlikely to match the business domains perspectives of information.
 

The discrepancy between the data store is due to a number of reasons independent of the quality of the original modelling. The reasons include:

• The data structures were defined to meet a particular system information requirement rather than to define the information within a business domain
• Data definition languages permit subjectivity to be applied to the data structures; the IDL does not permit subjectivity in the information structures.
• The data structures may include operational or target based information that is not part of the business information.

There are two stages, as shown in figure 5, in the congruency rules to reconcile data in existing data stores with the information defined in IDL models these are:

• Redefine the semantic definitions of the data in the data store to remove all multiple use of the same field and to create an explicit semantic definition for the extant data. Maintain the rules that link these two definitions
• Define the rules that reconcile an item of data with an explicit semantic definition with an IDL element at a business level

Figure 5 Reconciling data in data stores with IDL elements
 

It is usually necessary to define the information held in an existing data store as an IDL business model. This may then be used as the IDL end of this process but also as the gateway to the integration of the data in a data store.
 

The rules governing the reconciliation between the information held in an existing data store as an IDL business model may be relatively complex.
 
 

5 Rules used to find information on information
 

These are the Datawalk™ rules.
 

Datawalk™ is a rule driven facility to walk across a repository to retrieve the required information interactively.
 

Datawalk™ uses rules to determine the required retrieval from the information provided and makes the retrievals.
 

No knowledge is needed of the underlying data structures. The walker user only knowledge of the information to be retrieved.
 

Datawalk™ is a generic concept but invaluable in information management to retrieve the relevant information from a repository of information as individual users will be unaware of the actual content of the repository. The user poses a simple request and from the result poses another until all the information relevant to the search is found. This may be less or more than the searcher anticipated.
 

There is no limit to the length of the walk.
 

Within information management Datawalk™ is used to walk across a repository of IDL elements, conceptual data structures, and extant physical schemas to find relevant information.
 
 

6 Concluding Comments
 

The different types of rules are:

• Business level syntax rules. The rules defining the language for the definition of a business level information model in the IDL. These rules are a sub-set of the integration level syntax rules.
• Integration level syntax rules. The rules defining the language for the definition of an integration level information model in the IDL
• Business level validation rules. The application of business level syntax rules with appropriate action on rule transgression.
• Integration level validation rules. The application of integration level syntax rules with appropriate action on rule transgression.
• DL model evolution rules. The evolution of information defined for a business to an integration level model and finally as part of the single enterprise wide model.
• Presentation rules. The control of the presentation of models to ensure consistency.
• Congruency rules. How extant data relates to the IDL elements.
• Translation rules. The creation of conceptual structures from IDL models
• Datawalk™ rules to navigate a repository of information management information.

Final word
 

Without rule driven technology it would be even more difficult, if not impossible, to make the best use of information within an organisation.

# # #