25 February 2013

In many organizations, it's expected that any persistent data will be stored in relational databases that are managed by a central database management group. There are various reasons for such central control, usually centered around using IntegrationDatabases. Central data groups worry about keeping out malformed data, queries that can slow down important shared resources, and consistent data models across the enterprise.

Worthy these aims may be, but one consequence of them is considerable ceremony about storing data. I often hear complaints about change orders that take weeks to add a column to a database. For modern application developers, used to short-cycle evolutionary design, such ceremony is too slow, not to mention too annoying.

So application development groups tell me of using NoSQL databases to do an end-run around the DBAs. It helps that they are using a "mere datastore" here, not a "proper database". That way the DBAs can be kept out of the loop, often not told or happy to not care. [1]

There's both good and bad in all this. On the good side, this helps break what is often a troubling bottleneck for many organizations' application development. The sad divide between application developers and database professionals causes many problems, and the poor take up of many modern development techniques in the DBA community stifles much development. Shared databases are a poor integration mechanism, and NoDBA development leads to a useful push towards web services as the basis for integration. [2]

On the negative side, using a technology for social reasons can often lead to a poor use of the technology. It's not hard to imagine people using a NoSQL database to avoid the DBAs when a relational ApplicationDatabase would be a better choice. Data is often a vital asset, and bypassing DBA groups may also mean bypassing operations groups that know how to keep valuable data backed up and secure.

The real answer, of course, is engagement with data professionals along the lines of the devops movement. It's the barriers between groups that cause much of the ceremony, few data groups are populated by devils. We've seen success from inviting DBAs to stakeholder meetings where they get to engage with the broad aims of an application. We've also had NoSQL projects where we've reached out to the DBAs, helped them learn about this new technology, and got valuable help in supporting data needs. So although the NoDBA strategy is sometimes appropriate, engagement is often better.


As usual, I found the discussion of the draft of this article on our internal list very interesting. I particularly raided David Pattinson's contribution.


1: It seems particularly common to use MongoDB in this context citing MongoDB's ease of installation, configuration, and use.

2: A large part of the slow response to change requests is that many incumbent databases are in essence complex legacy applications at the centre of a large web of dependencies. These databases are brittle and untested (Detestable), so it's no surprise that the DBAs who look after them are wary of making changes. Such systems would make even the smartest developer gun-shy of making changes.