Us and them: The DBA – developer conflict

(Image credit: Image Credit: Moon Light PhotoStudio / Shutterstock)

Us (us, us, us, us) and them (them, them, them, them)
And after all we're only ordinary men
- Wright/Waters

“Us and Them”, as many will know, is a powerful song by the rock group Pink Floyd about conflict.  And, like it or not, conflict is a factor that runs through our lives, albeit limited (we trust) by good manners and the rule of law.  Similarly, in the business world, conflict is perennial and ceaseless:  sales v marketing; CFO (saving money) v COO (spending it); and, in the IT world, Database Administrator (DBA) (wants stability) v Developer (needs change).

I always enjoy the good natured banter at conferences between DBAs and developers.  A recent event was a good case in point.  Database administrators (DBAs) were portrayed acting like Gandalf and proclaiming to developers who tried to break “the rules” for application deployment, “You shall not pass!” There followed righteous indignation on social media – developers accusing DBAs of being boring and DBAs citing a catalogue of headaches that developers have caused them. 

Development functions have certain targets – responsiveness to business change, speed of development, quality of code.  However, their testing might not, for example, examine performance in a production environment. The DBAs might feel aggrieved that they have to pick up the pieces in tweaking the infrastructure to ensure the changes work at scale and in production.

Changing Fashions in Technology
The general sat/And the lines on the map
Moved from side to side
- Wright/Waters

Development fashions have changed over the years, as technology has delivered faster and cheaper storage and processing power.  In the 60s and early 70s, the limits of computer technology meant that business applications tended to be created as monolithic chunks of code, integrated from top to bottom to perform a prescribed business function. Then database products such as IMS, DB2 and Oracle came along and separated the important functions of storing and accessing the vital business data, and the role of the DBA was born.  In the 90s, improving technology enabled the creation of a middleware layer to take over the inconvenient matter of brokering access between applications and data – and the thin end of the wedge was first driven between application developer and DBA. Company boards (the ”generals”) took very little part in this, provided that IT delivered the right business function without blowing the budget too badly, and they merely watched the lines moving from side to side as these technology fashions changed. 

In the last five years the rise of digital transformation has seen open source databases, especially NoSQL and Hadoop, become more attractive to developers allowing them to create database instances without the need to comply with the rules of structured relational databases.  This evolution has led to a proliferation of structured and unstructured data within organisations that needs to be managed; as such sprawl is often a cause of vulnerabilities and reliability issues it has helped to widen the chasm between developer and DBA.  For developers, open source gives them more choices that are easily downloadable without the hassle of complex purchasing processes.  Combined with DevOps this gives them the ability to move much more quickly to understand and respond to evolving customer and market demands.  DBAs, on the other hand, must integrate this data from diverse sources to optimise the deployment for performance and availability.  Yet, their more measured approach can sometimes lead to frustration among developers, who definitely feel DBAs are not moving at DevOps-speed!

Thankfully in the last two years we have seen the relationship shift again. Developers are beginning to realise that the relational data model isn’t so bad after all, as it imposes order for better interrogation of data and improved data accuracy.  When applications need to respond in real-time to meet the demands of customers online being able to query data in a structured way has clear advantages.  At the same time DBAs are beginning to embrace the DevOps/agile mindset.  They recognise the importance to the business of being able to move quickly to deploy applications.  They are starting to understand the pros and cons of new features and functions and whether and how they’ll scale and fit into a production environment.

The Need for Togetherness
Me And you (you, you, you)
God only knows
It's not what we would choose (choose, choose) to do (to do, to do)
- Wright/Waters
 

An IT function is much more effective when DBAs and Developers choose to work together.

Developers should increasingly think about how changes will work in a production environment, for example with hundreds of thousands of users or transactions, rather than simply a test environment with dozens; they should consider data modelling much more closely. 

DBAs need to understand new features and functions as they come along and how they’ll fit into the infrastructure that it is their job to maintain.  Within this understanding there needs to be acceptance of a more agile, DevOps style implementation and management of databases - something that cloud database services go a long way to address.

And the CIO has a role to play here, in ensuring that the IT platform that underpins the business function has benefits for both developers and DBAs.  Postgres is a good example of such a platform – its extensibility enables it to work with a variety of programming environments and this appeals to a wider range of developers; and its architecture is less complex than the big databases, thus making the DBA’s life easier. 

Resolving the Conflict
Out of the way, It's a busy day
I've got things on my mind
- Wright/Waters

Developers and DBAs alike are busy people; by working together more closely, they can implement IT change more effectively, thus making both their lives easier, but both sides need to be aware of some key considerations.  For example, application developers must test meaningful data sets before they move into production environments and they should evaluate what application function would better fit into the database for overall system performance and reliability.  Above all, they should talk to the DBA about the database structure and how to build meaningful SQL, rather than just using the nearest handy development framework. 

However, it is not just the application developer’s responsibility to ensure the relationship works.  Database administrators must remember that it’s the application function that runs the business and be prepared to understand how new functionality fits within the business.  They should also be open to working with developers; rather than claiming lack of time, they should buy into the buzz of new things, such as DevOps and work out how the infrastructure can support these innovations.  DBAs can take steps to help developers with tuning queries that fit into the production environment.

Ultimately, co-operation, rather than conflict, must be the key. DBAs and developers must choose to work together more closely; and if they have access to a technology platform which facilitates this co-operation, then meaningful business function can go live that much more quickly and effectively.

 Jan Karremans, Senior Sales Engineer, EnterpriseDB
Image Credit: Moon Light PhotoStudio / Shutterstock