This editorial was originally published on 8 Jun 2015. It is being re-published as Steve is suspended out of time today, traveling to Australia.
At a Developer conference a short while ago, I was being talked at over coffee by a Dev Guy who was predicting the demise of the DBA. He had been caught up in the evangelism of the DevOps movement, but like many of his kind, had interpreted it as 'NoOps'. In his vision, DBAs were destined for a minor role within multi-skilled development teams, with the developer taking on ever-more responsibilities. I sipped my coffee and listened. I admired his enthusiasm but soon detected that he had little understanding of the roles of the several types of DBA, and of the other IT teams that ensure that successful application developments happen in any large enterprise. To him, it seemed as if a large part of the organization existed merely to confound and disrupt the best efforts of developers at delivering functionality.
DLM and DevOps aims to provide better communication, workflow and discussion between different teams in IT. However, some developers see an alternative future where their teams absorb other functions in IT, even in some cases taking over responsibility for maintaining applications and code in production. Instead of inter-team communication, there is, in this way of thinking, only one multi-skilled team. This is neither DevOps nor Database Lifecycle Management (DLM). There is a great difference between this rather Napoleonic idea, and the alternative of encouraging liaison, and ensuring that the requirements of operations, support and production-monitoring are built into application and database design, in order that they become an intrinsic part of the business domain.
DLM aims to ensure that the roadblocks in deployment are avoided by developing systems such as improved automated testing, and by encouraging scripting, but doesn't advocate trying to combine teams with different skill-sets and aims, particularly where they provide services across several development teams.
Whereas the multi-skilled Agile team that does both development and operations can be effective in a simple, IT-focused organization that specializes in social networking or internet shopping, it is dangerous to generalize beyond this. The organization of IT within an enterprise has evolved over the past fifty years in response to the increasing sophistication of technology. Functions such as audit, security and planning are there for a purpose. The reality of creating applications in an enterprise can come as an awful shock. The flow of data, and the interdependencies of processes and systems can be startlingly complex, as can the dizzying network and hardware requirements, and the requirements for compliance with legislative frameworks and practices. In systems with any financial component, the test requirements before deployment can be extraordinarily stringent. There are operational requirements to factor in, training issues, support, licensing to check and security to put in place and test out. There is a lot to communicate about.
The Dev Guy paused for breath. I refocused my attention, and opened my mouth to try to point out that there might be an alternative and happier future for the profession of the DBA. Something about his stare made me pause. I wasn't going to win this. "Well, I suspect you could be right" I muttered, before hurrying off to the next presentation.
