Guide S35 -- Management Guide to Custodianship

• S35 Table of Contents
• Integration Process and Issue Management
  • Identification And Resolution Of Data Changes
  • Project Responsibility For Changes
  • Characteristics Of Integration Issues
  • Roles Matrix
  • Process Flow
• Previous | Next

Integration Process and Issue Management

The process of building and maintaining a corporate database is complicated and takes a lot of cooperation and coordination between the areas of the ministry that are custodians of information and applications. This section will describe the process that is required to develop and maintain the corporate database while developing and maintaining the applications that work on the corporate database. Any change to or deletion of a data structure in the corporate database needs agreement and planning by all the custodians of applications that access that data.

Identification And Resolution Of Data Changes

1. The triggers that will bring the data issues to light are:
   • Business Area Analyses
   • New Applications
   • Releases of Applications (which include changes in business rules, new legislation, user requested enhancements, etc.)
   • Information Access (ISB program to deliver copies of corporate data to office LANs)

   Note: What is likely to happen in the Information Access scenario is that a user may discover that some data they require is not available or is not defined as they require it. The process for resolving issues triggered by Information Access will be the same as described below except that since the issue will not have come to light during a project, the issue will be referred to the Data Custodian to initiate discussions.

2. Issues will be identified through data modelling done in the projects. Data issues may also be recognized before the data modelling process identifies them; they should be dealt with when identified by the Data Standards Manager(s) involved (see Definitions).
3. The Data Administrator (Information Systems Branch) and the Data Standards Manager(s) involved in the projects are responsible for identifying the issues.
4. The Data Standards Managers for all the branches affected by the data issue and the Data Administrator will meet to clarify the requirements, define the issues, assess the impacts, define the alternatives, and finally to produce a recommendation to proceed. The recommendation to proceed goes to the Project Sponsor.
5. If the issue cannot be resolved at the Data Standards Manager level, the issue must be referred to the next level of authority: the Project Sponsor. A Data Issue Bulletin should be developed that describes the issue, the effect to ministry business, and alternatives. The Data Issue Bulletin could be initiated by a Data Standards Manager or the Data Administrator. The bulletin will be distributed to the relevant Data Standards Manager(s), Data Custodian(s), Application Custodian(s), and the Project Sponsor. The Project Sponsor and the Data Custodians will resolve the issue with input from the Data Administrator as required. The Project Sponsor will be supported by the Project Manager and the Data Custodians will be supported by the Data Standards Managers.
6. If the issue cannot be resolved at the Project Sponsor/Data Custodian level it will be escalated to the Executive by the Project Sponsor.

Project Responsibility For Changes

1. The Project Sponsor is responsible for ensuring the planning is done for the changes being scheduled. This means it is their responsibility to ensure that all Application Custodians who have to modify their applications because of the change to the database, plan and schedule their projects to coincide with the database change.
2. The Project Manager responsible for the project that initiates the database change(s) is responsible for documenting the application dependencies in the project plan so the DataBase Administrator (DBA) can ensure the changes made to the database have been approved by all the Application Custodians affected. The method the DBAs have to ensure that all approvals have been received is by comparing the signatures on the migration requests to the dependency list in the project plan. The DBA will refuse to make changes to the corporate database when they have not received approval for the changes from all application areas affected. The DBA has the ability to check that all the applications that could be affected have been listed in the project plan.

Characteristics Of Integration Issues

All changes to data stem from ministry policy/procedures, which means that a change in one policy/procedure that causes a data change in the corporate data model may also require change(s) to other policy/procedures.

Any addition, deletion, change in size, or change in definition to a piece of data in the corporate data model has the potential to affect every application that uses the corporate data model, whether the applications use that particular piece of data or not.

Depending on what the change is to the piece of data in the corporate data model, the scope of change(s) required to applications and policy/procedures may be small, very large, or somewhere in between. The only way to understand the scope is for the Data Custodians and Application Custodians to have the policy/procedures and the applications analyzed. The effect of the changes must be analyzed with regard to the ministry as a whole on the basis of cost, timeframe, effort required, and the effects on people and the business.

Funding for maintenance of and enhancement to the ministry's applications comes out of STOB 25 (program Branch or Operations Division responsibility centres). The Application Custodian is responsible for funding maintenance and enhancements for their applications; in addition, an Application Custodian who creates a change must ensure other affected Custodians are able to fund any changes they would then require. If not, it is the creator who must either escalate the funding problem or fully support its escalation, including informing the Director, Information Systems.

Roles Matrix

***Roles matrix not available in HTML format at present***

Process Flow

The process flow diagram [12kb] shows a general procedure for implementing change within a modelling or systems development project. (Note: in May 1997 the definition for "Data Resource Manager" changed to mean staff who collect and manage data, and the term "Data Standards Manager" began to be used for the Data Custodian's staff help. This diagram has not yet been updated with "DSM" wherever "DRM" is displayed, so when you see DRM, it really means DSM!)

ToC
Top | DA Home
Last modified December 21, 1999