Database Change Management
Introduction
This is the most challenging job as far as software or database developments are concerned. In the field of software, customers and the project managers are always asking for changes in the delivered software system. If these changes are done in ad hoc manner you will end up with a mess. To overcome this challenging task you have to adopt some management experience. For most of the time we, developers encounter difficulties not in developments but in managing them.
Having in the field for just over ten years in the database management and developments field here are some of my practices. You also may have some different ways of achieving this. I would like to welcome you to participate with your comments on this discussion.
Phases of the Change
As far I am concerned, there are four phases in the "change".
- Change Request by developers.
- Change Analyze
- Implementation
- Record the Change
Change Request by Developers
First developers have to request the changes in a predefined format before
implementing the changes. This format is depending on the type of customers you
have. The following format is the one which I adopted.
| Request ID:
| Request By:
| Date:
| |
| Customer / Project:
| System:
| Database:
| Item(s) need to be changed:
|
| Type of Change: | |||
| Description:
| |||
| Components Need to be Changed:
| |||
| Comments:
| |||
Let me briefly describe the above format. Request ID is a unique id to identify the "change". You can use some means to give better indication to this ID. for example you can include user code , system code or the database code to this ID so that it will be much easier to identify the change the from the ID itself. Customer / Project, System, and Database is much important when you are in the process of developing multiple software systems for more than one customer. Tables, Views, Stored procedures, Triggers that require change can be included in the space allowed for Item(s) need to be changed. The developer can enter whether it is a new item or deleting existing one or modifying the item. if it is modifying, developer has to specify what he is going to modify. Description is the comprehensive description of the "change". Here you have to specify why this change is needed. Components need to be changed is very much important parameter in changing the database. As always the case in databases, on change may lead to change in one or more components. At this place developer has to specify what the other components that needs to be changed. Comments column is the space which allows developer to enter additional comments of the change.
After filling this format, the developer has to pass this to the database owner who is responsible for the whole system.
Change Analysis
After getting the request, the database owner has to analyze the change. His first task would be to find out this change is one that is really needed. If this can be done by using the existing database he must reject this by indicating the ways which can be achieved.
His main task would be to find the other components which will be affected from the "change". Even though the developer has mentioned this, database owner has to study this carefully to identify the other components. His duty will be to inform his findings to the other components' owners and the project owner. Having informing the project owner he will not release the system until all the components have been changed.
Implementation
After accepting this database owner passes this to the developer and project manager. Then database owner can perform the necessary changes that were requested by the developer.
Recording the Change
This the most important stage. For future reviews this recording of the change is very important. You may use a simple table for this recording. This recording is very useful when it comes to the analyzing part for the next change.
Further Improvements
This process can be automated. A Simple tool can be developed so that it will be easy for all the members to view the changes requested and accepted. When a request is made it can be automatically email to the user and when the changes are accepted mails can be sent to all the components' owners for those components that need to be changed.
Conclusion
As I mentioned earlier, changes are the headaches which is part and parcel of software development. If we can adopt the systematic way, then we can meet the changes without any fear. I accept that this process would time
consuming. But I think sacrificing this time would be better off rather than going into a mess.
