At one point, test database deployments within my department were handled directly by the database developers. The typical process was that the developer would unit test their changes in the development environment, then:
1) Migrate their changes to the test environment.
2) Send an email to the testers to let them know the changes were available in the test environment.
This was a solid process, which typically took only a few minutes to complete, and was nearly always completed successfully.
However, at one point the head DBA for my company took away all database owner permissions from the database developers on the test environment so that test database deployments are now handled only by DBAs. Over time the process morphed into the following:
1) Database developers complete a 15 page form to list the changes they need to migrate (for a typical deployment, most sections are blank, but the applicable sections are scattered throughout the form)
2) The database developer completes a 1 page script header for any migration scripts involved in the plan
3) The database developer references a deployment project containing all of the objects to be deployed in the plan
4) The database developer sends an email to the department head requesting the deployment
5) The department head approves the plan, scripts and project
6) The department head forwards the email to the primary DBA for the database
7) The DBA either approves the migration, or rejects it (typical rejections are due to a section of the 15 page form or 1 page script template not being filled in, or the 15 page form not being the most recent version of that form)
8) The developer completes a 2 page form email to the testers, letting them know the changes that are scheduled to be migrated
9) The DBA sends an email to the developer and department head letting them know the deployment was complete. Or alternatively, that it could not be completed.
10) The developer replies to the 2 page form email, letting the testers know the deployment was completed.
So, a process that once involved a single person, took less than five minutes to complete and had a near-zero failure rate now involves a minimum of three people and takes a minimum of twenty minutes to complete. In addition, deployments submitted after 2:00 PM often cross over into the next day based on DBA and department head availability.
Along similar lines, the head DBA has published a 50 page standards document. The majority of the document is focused on what he feels things should be named, the use of acronyms, underscores, capitalization and so forth. However, it also includes some time-consuming non-functional requirements. For example, adding database descriptions to all parameters for all objects. Or requiring all constants used in the database to be drawn from a numerically keyed constants table. Which means that execution plans can't be optimized based on the values for the constants. The 50 page standards document also includes a number of prefix/suffix naming conventions that are now considered industry anti-patterns.
The head DBA often refuses to deploy anything that does not conform to the latest version of this document, which changes on average every two months and often reverses previous positions. Ostensibly this is to 'raise the standards used in the department' but in reality quality has fallen off considerably since he implemented these policies. The time that used to be spent improving the existing code base and adding new features has been diverted to renaming database objects and regression testing the changes. The database developers in the department estimate they now spend 40% off their time dealing with standards and processes put into place by the head DBA. All of which have a negative or no impact on the performance and stability of the applications supported by the databases.
Has anyone out there had luck dealing with inefficient DBAs? Or alternatively, have any similar stories they'd like to share?