misused - part 2

the database administrator

This would be an easy part 2.  I could simply copy and paste all of part 1 as it certainly all applies.  I want to take it just a bit further though, because this one still  baffles me in a lot of respects, in a lot of places.

Through my professional career, I have had the opportunity and privileged to not only meet and work with a good number of DBAs, but also to manage different people in this role over a period of 12 years.  I have come to understand their passion for data, for the query that can turn raw data into useful data, and their ability to manage the care and feeding of data, from the bits laying around on the hardware, through the schema, massaged by the application, and finally displayed to the consumer by which point the data should now be information.

The befuddlement for me is how much a typical organization ignores their data, and therefore the people that take care of it.

After people, this is the next most important part of your organization.

The above is true even if you do not own a computer.  At the lowest level, accounting is data driven, and even if you claim to not be in business for money, you still have to report taxes and keep track of your funding to keep rolling.  Most businesses these days run on data, and it is used in multiple aspects of a successful organization.

If you sit back and realize this, then ask yourself a few questions.  Start with "is my data in good shape?" and lead on to "how do I know it is in good shape?" and "what have I done to ensure its integrity?"

Would it surprise anyone to know there is no such thing as a perfect database?  A database where all the information is accurate, all the indexes are used correctly, and all the integrity is correct? 

It does not exist.

Here is only some of why:

People enter data into databases.

People write code that interfaces to databases.

DB engines at time have bugs and issues, and are evolving.

Integrity checks are an evolving animal.

Schemas are created by people, or sometimes worse, by programs written by people that understand data structures very well, but not your data structure.

Mirroring, replication, clustering, sharding, etc are all evolving practices.

...and the list goes on.

All the above items play together in their own harmony to ensure the perfect database does not exist. 

Do not despair, all is not lost.

You have available to you a very special person or even team of people.  These people live, eat, and sleep data, data structures, database schemas, relations, indexes, engines, and all those things most have only heard in passing.

Much like the systems administrator in part 1, did you invite them to the party, or did you look at them as only a custodian of something tossed at them after the fact with the expectation they keep it running and healthy?

If you fall into the latter category, Why?  It does not have to be that way.  It should not be that way.  IT works better when it is NOT that way.

Bring them into the team up front.  Enlighten them of the problem the team is trying to solve, and be ready to be surprised when they come up with a solution to the problem you have never thought of, or an idea for the team to consider that may change the path of the project and eliminate an obstacle everyone else thought would be the most difficult aspect.  Be prepared to see them as a team member, not a data slinging automaton.

Be an agile leader that allows this to happen.  Remove the roadblocks and the mindset.  You will not regret it.

Be the database administrator that provides input to an entire project team.