It’s tough to be a DBA these days. Gone is the time when a DBA’s primary job responsibilities were to keep the database 1) up, and 2) fast.

Today, that’s still the DBA’s responsibility, but the scope of their efforts has increased dramatically. Security teams have imposed more stringent rules on how database access is controlled, audited, and validated on an ongoing basis. Compliance auditors require increasingly strict levels of documentation about things like backup and recovery testing, change controls, and other best practices. Corporate ITIL initiatives expand the quantity of people who have to be involved to implement even minor fixes, upgrades, etc.

Then, on top of all of these other things, the database technologies themselves are getting broader and more complex. More and more capabilities that used to be under the auspices of systems or storage teams are moving into the database teams – technologies like Oracle Data Guard replacing storage-based replication, or data warehousing appliances replacing traditional servers.

With the intersection of all of these things – some organizations have decided that the only way to cope with this growing level of complexity and compliance requirements is to standardize through scripting. The logic is that if a senior DBA scripts out the build, patch, security process, then junior DBAs can reuse that logic over and over again.

The reality, though, is that most DBAs are not developers. Perhaps, at some point, they were part of a development team, and many DBAs can write scripts. But that’s different than development.

How so? When someone writes a script, there’s usually a series of fixed inputs, some basic logic, some error handlings, and then a series of outputs targeted towards success or failure. The script itself is process-driven – start at point A, then go to B, then jump to D, then end.

Scripts, by themselves, are useful – they can handle routine operational tasks, streamline repetitive behavior, and in general make things run more smoothly.

That’s different than developing an application, though. With development, you gather requirements, you design an architecture, you have best practices, you develop libraries and reuse code, and you have documented QA plans. Scripts are usually written by one or two people, while software is developed by teams.

Database automation is an application. It’s not enough to say in a script: “first, install Oracle, then, upgrade Oracle, then, create a database”. Because that doesn’t really cover the breadth of what’s required. What happens if a patch needs to be installed on top of the Oracle installation? What if the environment you’re installing is clustered, what changes? What if there’s already an Oracle installation in the directory where you want to install – but it’s the wrong version? What if the user wants to use a database option the organization is not licensed for?

Something that starts out as a simple script – perhaps a hundred lines or less, suddenly balloons to thousands of lines of code, with libraries, dependencies, certified platforms, test plans, product roadmaps – we’ve seen this happen at organization after organization. Suddenly there are 30MB tarballs of code that get copied around to do database builds and patches, and like it or not, those scripts have become an application to be maintained.

The DBA and the rest of the DBA team, whether they planned it or not, have now become a development organization. They hadn’t planned to, it wasn’t in their overall goals, or roles and responsibilities, but it is now.

The tragedy of this is that DBAs are worth so much more as DBAs than as developers. All of the complexity described above, all of the features and capabilities to be taken advantage of, not to mention the core aspects of schema design, performance tuning, and data availability – that’s where DBAs add value. Organizations have development teams that write software, and DBAs that help those developers store data and access it efficiently, and keep an eye on what the developers are doing for best practices. DBAs shouldn’t have to be developers too.

This is why we believe that wanting to streamline the complexity in the database environment, as well as coping with the compliance and security requirements naturally leads to the idea of database automation. It’s just that trying to do that in-house will most likely fail. In the best case scenario, it takes your valuable DBAs away from their core mission, and turns them into another development team.