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.
 

Misused - Part 1

the systems administrator

All too often in my career, the systems administrator has been the role of the misused. After 20 years of being one, managing many, understanding how they breathe, what they thrive on, and what they are capable of, I can tell you this. The company matters not. The size of the organization matters less. The leadership, ah, there is what matters. A good systems administrator will be a silent type. You never have to hear from them  because they are always behind you, trying to making whatever it is you dreamed up to work. Tirelessly working out its issues, they are; sacrificing time after many have become pillow-fodder.

Why?

They believe this is what their job is, what their roll is in the big picture, and they have been trained and engrained to believe it since about 20 seconds after the computer was invented.

It does not need to be this way.

What if...

...they were an equal member of a kick butt team, able to provide input, be listened to and listen in alike.

...they assist in designing the road that carries everyone forward, pointing out where the path can be straighter and faster.

...instead of being handed something to make work, they have a hand in making it, so it works. Making it so it can be supported. Making it accomplish.

...allow them to do, to make, to attempt, to fail, to learn as a team, on the project, at the start.

You can. It works. I have seen it. I have done it.

If you have a systems administrator, you have, first and foremost, a person. Get to know them. Understand their strengths and what drives them, then tell them where you want to go, not how to get there. Work with them on solving the mutual problem and be amazed at what they know, and what they can accomplish as an equal team member from the start. Consider the following:

Do not ask for "a server". Ask for assistance solving a problem that requires resources and their expertise, then do the same for the network it rides upon. Work together on the design as engineers of network, server, code, delivery, monitoring and those things that are important to the operation of the problem solving solution.

Do not throw it over the fence. It does not matter what "it" is. No ownership will ensue. No digging in will commence. No availability will survive. Nobody will stay around.

Be an agile leader that makes this happen. You will not regret it.

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