Problem solve Get help with specific problems with your technologies, process and projects.

Developer and DBA: Working together for greater efficiency

There is often a disconnect between developers and DBAs. Bridging the gap between database design/development and operations management can make the difference between an efficient, well-managed business application and one that fails to meet service-level expectations.

When was the last time you checked to see that developers and DBAs within your organization were working together collaboratively?

Contrary to popular belief, there is often a disconnect between developers and DBAs, and a risk of the gap widening further. Bridging the gap between database design/development and operations management makes the difference between an efficient, well-managed business application and one that fails to meet service-level expectations. Working collaboratively decreases the inefficiencies that result in higher operation costs.

With less time and increased complexity and pressure, collaboration and teamwork seem to have collapsed, resulting in increased finger pointing and unnecessary escalation, impacting business costs and efficiency. This trend reinforces the importance of IT governance and alignment.

As business and technology change, the roles, responsibilities and activities that support and manage it must change as well.

Discussion on the topic at major database user conferences revealed that deployment of new applications involving J2EE, .NET and Web services technologies were viewed as increasing the challenges and work for DBAs in areas of problem determination, isolation, repair and overall service-level management. Developers once skilled in proper SQL constructs and query execution path optimization methods are now replaced by developers and new methods that generate database-independent code and utilize JDBC, JSQL, SQLJ, ODBC and Web services for database connectivity.

With developers focusing more on object-oriented methods, they no longer code specific to SQL by database type, enabling greater code portability. This further reduces the need to engage with DBAs and is seen as another way to reduce project cycle time.

In response, DBAs are increasingly frustrated; they feel they have ended up with the short end of the stick, viewing data retrieval and query performance as a fine balance of proper application design and infrastructure capabilities, to which they only have partial control.

Identification of operational inefficiencies, or gaps, must begin immediately after business requirements are gathered and the design of the database is initiated, not after production. It's essential that developers consult with the network, systems and database administrators to ensure current infrastructure capabilities are reviewed and considered. If it's mutually determined that capabilities don't meet requirements, management must either re-scope the database project or secure additional budget for the additional hardware or management software required.

After proper design and development are completed, the developer and DBA must meet again to review the final database code and functional testing. Review of the resulting SQL and expected and tested execution path further reduces the risk of performance problems and eliminates surprises once the code is placed into production by the DBA.

Once code is placed into production, it must have the proper administration and change management. Although the DBA performs the database object maintenance, he must also communicate changes to developers so the original model and design are updated. This eliminates the risk of erasing changes made in production when new application updates or patches are deployed.

Performance tuning is a shared responsibility between developers and administrators. It's reliant upon the application design, transaction execution and orchestration across a complex infrastructure of application servers, networks, databases and servers.

With changes in business, employee turnover, reorganization and management by reaction, staff can quickly lose sight of practices previously put in place. In some organizations, change is not occurring quickly enough, and the divide is dangerously and negatively impacting business and customers.

Barriers to communication and collaboration must be identified and repaired to enable a smooth workflow from database design to production. Reinforce your team to move away from the "us versus them" mentality and focus their responsibilities on preventing poor-quality code from being developed. People, processes and technology must integrate and seamlessly flow to support business no matter the boundaries that may divide them.

About the author:
Steve Lemme is a director of database management solutions for CA, published author of Implementing and Managing Oracle Databases and columnist in Database Trends and Applications Magazine. Mr. Lemme is an Oracle Master DBA with over 15 years experience in mission-critical Oracle architecture and speaks on database management best practices to address regulatory compliance. Prior to CA, he managed critical computer and database systems for Allied Signal, Apple, GTE and Motorola, where downtime was $150,000+/hour. He holds the position of director in the Independent Oracle Users Group.

This tip originally appeared on

Dig Deeper on SAP development and programming languages

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.