One of the things that I often hear from Developers working in DevOps or lean, agile type environments is that failure must be tolerated, or even encouraged. This is important in building a culture of experimentation and learning. We need to try new things, and if they work well, teach others and expand their use. Not every experiment will succeed, so we want to fail fast and early, and also ensure that others learn from our experience to avoid repeating that particular failure item.

Is that the case for DBAs? Are we allowed to experiment and fail? I'd like to think so, though in some ways we need to be more careful with how we experiment. Since the database is that place where we have lots of data and information, our failures can be much more widespread and impactful than a new feature or function not working in software. Certainly the potential problems of exposing lots of data to unauthorized users is a problem.

As an example, many of us find databases that have poor security models set up. Whether we have "sa" being used by applications or ad hoc permissions added to random accounts, there are better ways to implement data protection. Just changing the permissions for objects, however, isn't the type of experiment I'd run. Instead, I'd look to add a new user account with no permissions and slowly experiment with adding that account to a new role, starting to assign new permissions and determining if this meets the needs of other users.

This is the same type of experiment I might conduct with a schema that I need to evolve. I'd make a copy, move some data, perhaps in a second database where I use views, synonyms, and other objects that can help me understand the impact of making design changes on my application. If I've captured the scripts in a VCS (perhaps a branch), and documented the changes,  I could easily repeat this in the future in my production database, knowing the steps to follow that will minimize disruptions.

As a DBA, I've often been very conservative and careful in how I approach the administration of databases, which includes the deployment of schema changes. Unlike many other DBAs, I haven't viewed my goals as an impediment for developers, but rather a challenge to get work done in a save way. This might include trading time and space to limit disruptions, but always ensuring that we can get enhancements to customers, whether they realize it or not.