Application first database second

“Application first database second” said the scrum master. I had an interesting conversation with a colleague about the philosophy underpinning his development methodology.  We were discussing the merits of solid data modelling underpinning  the agile method.

I’d been considering this topic in Agile DBA

His criticism of spending  an excessive time creating the ideal data model – impinged upon the project deadlines. Data Architects were spending so much time gathering and analysing requirements , they weren’t able to shift product  and new functionality to customers.

His mantra of “Application first database second” focused his developers on developing quickly – usually in 3 week cycles, and the DBA much closer aligned to the development process. Traditionally, the data architects and DBAs were develop the data model, implement and occasionally review the model . he found this approach inflexible and ultimately uneconomical.

DBAs are normally fully tuned in to solid database design principles. Designing database systems that scale. The relational model represents these ideas. ACID (Atomicity,Consistency,Isolation,Durability) remains a fundamental tenet of database design patterns.

How does the DBA \ Data Modeller deal with this Application First Database second?

1)      Although it’s a seductive phrase, I do think agile developers need to be selective. One of the essential aspects of DBAs managing agile platforms is the requirement to maintain a stable and available platform.

Certain applications need in depth modelling . For example, risk modelling application with a heavy emphasis on number crunching are candidates for Database First Application second. The queries run for extended periods of time . Poor design could lead to poor performance. Poor performance can lead to delays in reports which could have a financial impact.

2)      DBAs need to focus on technical excellence. Technical excellence lead to increased agility.

3)      Database code is treated the same as application code. This is a challenge conceptually . Although we think of database code as logical, there is an aspect of database code which requires optimised access to memory and disk. The larger the data sets and complicated queries the greater this becomes. The DBA needs to be mindful of the query impact.

Let me know your thoughts

Read More on database design

Database Architect versus Data Architect - DBA DB2

DB2 database design : physical design is important - DBA DB2