Our system has a huge database of information that it stores. Some database tables have 100 million plus rows. And there are hundreds of database tables used. Development makes changes to the schema throughout the year. These changes need to be tightly controlled to prevent chaos from spreading.
In the past, the DBA team implemented a process to control all changes to the database. Requests would be made for the changes. All the teams would approve the changes. The DBA team would promote the changes to development, test, and then production. Changes were grouped into releases to minimize the work to implement the changes. This arrangement worked well most of the time.
Somewhere along the line, a team of consultants came in to help re-architect the system. Unfortunately this re-architecture was a complete disaster. The customer eventually pulled the plug on the new system. Development was tasked with restoring the old system. Through some miracle the consult team remained on the project. And now they are working to take over the change management for the database.
Previously the DBA team had a good rapport with the rest of the development team. So the database change management ran smoothly. Now there is a fight for the control. There was no clear edict that appointed the consultants as the maintainers of the database. In fact, they do not actually implement any changes. The DBA Team does that. The result is that there is not a clear direction on how to initiate changes for the database.
The management team is aware of the current situation. And they have their own objectives to achieve on this project. At about this time every year, we need to start making monthly changes to the database in preparation for next year’s release. The database change process needs to be ironed out and the control issues resolved before we can perform this task properly. It seems that politics is getting in the way of technical progress once again.
