Editorials, Ethics

The DBA Code of Ethics

In April of 2006, we worked out a code of ethics for DBAs.  I wanted to post it here and get your feedback.  I think it pertains fairly well, even after more than 11 years.  What would you add or change?

This cannot happen in a vacuum though. It takes your feedback, your comments. I’ll do my best to pull things together, but we need to have discussions and thought going into what makes up a responsible code of ethics for the DBA profession.

Getting Started
I think a “code of ethics” exists to help guide “what’s next” when you look at your position dealing with databases. This includes task-based things – what tasks do I do next to support the data systems. It also includes doing what’s next when problems arise.

Here’s a first pass at how we might be able to structure this. I think we have three different things we’re responsible for. No order to these headings or the items within them at this point.

Responsibilities to the Company
– Be aware of and up to date on regulations that impact data systems.
– Keep the company advised of all issues, honestly, openly and without unneeded drama.
– Provide complete information with all facts available.
– Provide the best possible security for all data systems.
– Provide a recoverable environment, with a recovery plan and awareness of how to execute on that plan.
– No silos – avoid segregating knowledge about your systems, techniques.

Responsibilities to One’s Self
– Stay up to date on industry happenings.
– Stay up to date on regulation and other non-technology things that touch data systems.
– Continue to learn new techniques, new tools, understand best practices.
– Strive to constantly be tuning and improving approaches and procedures to existing processes.

Responsibilities to Co-Workers
– Be honest in all dealings with co-workers.
– Protect co-workers from data systems.
– Share, teach and help grow the collective knowledge base.

So there you have it – what needs to be updated?

  • Ed Zerylnick

    Never use the company’s data for personal use/personal gain. It’s the company’s data; not yours.

  • GaryM

    Protect co-workers from data systems? Not sure what this means. Does this mean from changes to internal processes leaving the co-workers interaction with data unchanged? Does this mean not storing identifying information on records that should be anonymous? Restricting access so they do not get confused? (last one is a joke!) Also, it has been my experience that the item “Be aware of and up to date on regulations that impact data systems.” typically falls largely to application groups and legal department with DBAs being called on as needed.

  • Ed Zerylnick

    Maintain the confidentiality of the data in your care. Do not divulge information about the company’s data that is not a public record.

  • Martin S. Stoller

    Stephen, this looks pretty good, and many of us veteran DBA likely instinctively follow a version of this code.

    But maybe the cardinal rule is missing here (and I’ll get to WHY in a bit)?

    Responsibility to the DATA:
    – Preserve and safeguard the data exactly as you received it. Never modify it, format it, re-type it, or change any of its metadata (ie nullability, default constraint, etc) without an express and documented request from the business.

    That is the single main rule – and duty – we DBA _need_ to follow. If we do that, the rest sort of follows.

    Yes, I know preserving and safeguarding our data is OBVIOUS to senior DBA… but it often is not something new or accidental DBA even realize, as I’ve found out too many times.

    We have to remember that DBA are digital librarians – all we need to do is safeguard the data entrusted to us, with whatever means we can, so that when the business asks for it back, they will find it the same as when we received it.

    Often I talk to new DBA or DBDevs about a data problem they have. An example: I had a DBA/DBDev once that wanted to reformat all customer names to all caps just so the list of customers would look nicer. They didn’t grok that messing with the data at their level (ie DBA and not BA) in any way would have affected downstream usage. In this scenario, someone had a report that was looking out for customers with all caps vs mixed case, because they knew the all caps customers came from an acquisition (yes, awful example, but a real life one – the app had no flag for identifying customer source).

    Now if a BA (Business Analyst) decides to do the same thing, that’s fine. It is their job to make sure data changes do not negatively affect the business!

    Just my two kopeks, of course. 🙂


  • Ed Zerylnick

    As a DBA you have great power – do not abuse it. Maintain standards but do so with as much kindness as possible. Do not make anyone’s life hell.

  • AZJim

    “With great power comes great responsibility” (source: either sage advice from Uncle Ben in the movie Spider-Man or Voltaire – you take your pick).

    As you mentioned, regulatory compliance is number one for your company and industry (PCI, PII, FDIC, FINRA, SEC, GLBA, HIPAA, CJIS, NIST, SOX, etc. and all the international equivalences for global companies).

    But at a tactical level, something that might be more important for an organization is an accurate turnover file. If your colleague gets hit by the proverbial bus, wouldn’t be nice for you to have a document detailing the issues relating to job anomalies? For beginners, I would require in a document special scripts and their locations, inventory (yes, surprisingly many DBAs don’t keep an inventory), special intervention details, points-of-contact, HA/DR tier levels, and special password or encryption usages.

    For what it is worth (I am speaking from experience).