Reaction Time Is Critical
When I speak about agile database development techniques at conferences, I like to ask the audience whether they could successfully rename a column in a production database and deploy that change within a day. Many people in the audience laugh because they know that their organization is unable to accomplish this obviously trivial task. I asked a similar question in the survey, and the results are summarized in Figure 4 by organization size. Interestingly, once again we see the same trend from Figure 2.
On average, 11 percent reported that it would take 3 months to rename a column, 7 percent said it would take more than 3 months, and 8 percent worked in organizations where they felt it was far too risky to even attempt to rename a column. Too risky? Yikes! Seems to me that those organizations have convinced themselves that it's exceedingly difficult to evolve a relational database schema. As Pramod Sadalage and I show in Refactoring Databases (Addison-Wesley, 2006), this is not the case—regardless of how tight the coupling of external programs to the database schema, even when hundreds of heterogeneous programs access the database, it is possible to safely and rapidly make changes. Better yet, we show you how to make database changes that offer significantly greater value, such as moving a column to another table, splitting a column that is currently being used for multiple purposes, and fixing data quality problems.
If you can't easily evolve your database schema, or improve the quality of the data within it, then clearly, you can't respond effectively to changes within your business environment. Nor can you easily fix the problems within your database, problems that will only cost you more and more money over time. Look at Figure 4 again, and ask yourself how many respondents appear to work in organizations where their databases are an anchor around their necks, and not the assets that they desperately want them to be.
