Av rating:
Total votes: 25
Total comments: 8


Brad McGehee
A Code of Conduct for DBAs
03 September 2009

Despite the fact DBAs are protectors of an organization’s knowledge, and privy to much confidential information, there is no clearly defined set of rules and standards to help govern and guide their ethical conduct.  Brad McGehee, in an article based on a chapter from the second edition of his book How to Become an Exceptional DBA, discusses a Code of Conduct for DBAs. He advises on why such a code is required, the sort of topics it should contain, and how it might be enforced. Much of this article has relevance for any IT professional.

Physicians, attorneys, accountants, engineers, realtors, and many other professionals have written guidelines designed to discourage misconduct and illegal activity, and to promote the ethical conduct of its members. In fact, according to the Sarbanes-Oxley act, all public companies in the United States are required to create and follow their own code of conduct.

if, as a DBA, you
identify criminal
behavior within
your organization,
what do you do?

However, despite the fact that DBAs are essentially protectors of an organization's knowledge, and privy to much confidential information, there are no clearly-defined set of rules, values, standards, and guidelines to help govern and guide their behavior.

In this article, I define what a code of conduct is, explain how it can be useful to DBAs and the organizations they work for, and consider if and how it could be enforced. Finally, I offer my take on a "Code of Conduct" for the Exceptional DBA. Rather than be prescriptive, my goal is simply to offer advice to DBAs on how they might conduct themselves within the bounds of the professional responsibilities of their job.

What is a Code of Conduct?

Generally speaking, a code of conduct is a set of formal, written rules, policies, standards, guidelines, obligations, behaviors, expectations, and principles that are voluntarily adhered to by a group of people with similar goals, values, and responsibilities. While other definitions exist, this one will serve our purpose well enough, as we seek to define the standards of conduct to which a DBA should adhere, while carrying out their professional duties.

NOTE: For different perspectives on this topic from other IT professionals, you can explore these websites that contain Codes of Ethics: The Association for Computing Machinery's (ACM), or the Association of Information Technology Professionals (AITP)

How Can a Code of Conduct be Useful to DBAs?

To many people, a "Code of Conduct" means one thing: more rules. Most DBAs, myself included, would consider themselves mature enough to make their own decisions and choices, and are naturally resistant to the idea of someone telling them what to do and how to do it.

If this is the case, then why have I written this article? Well, first, my intent is not to offer a set of rules that have to be followed but, instead, a set of guidelines that can be useful for DBAs who want to fully understand and appreciate the nature and scope of their duties and responsibilities. In other words, it is intended to be educational.

It's a sad fact that
many organizations
don't fully understand
and appreciate the
true role of a DBA.

At a fundamental level, most DBAs believe they understand what it means to behave "ethically". In my experience, instances of willful negligence, or blatantly unethical behavior, are relatively scarce in our profession. However, there are many "grey" areas where a DBA, especially a less-experienced DBA, can find themselves unsure of where their responsibilities end, and how exactly they should respond to a potentially compromising situation.

For example if, as a DBA, you identify criminal behavior within your organization, what do you do? Hopefully, your answer would be that you'd report it. However, is that the end of your responsibilities? What if the company you work for does not respond appropriately? What further action should you take, if any?

It's a sad fact that many organizations don't fully understand and appreciate the true role of a DBA. In their attempts to save money, they sometimes cut corners that can directly affect the integrity of their data, and so unwittingly place the guardians of their data in a difficult dilemma. If you find yourself in this situation then, hopefully, this code of conduct may help convince your organization of the importance of the role of the DBA, and the need to employ experienced DBAs to safeguard their business data. For example, if you are having difficulty convincing your manager to adhere to government regulation that affects the data you manage, then referring the manager to this Code of Conduct might be useful.

Perhaps above all else, the "Exceptional DBA's Code of Conduct" can be a source of pride to all of us who choose to adhere to it, and give us more confidence that we are doing the best we can at our jobs.

How Should a Code of Conduct be Implemented and Enforced?

Whenever the topic of a "code of conduct" is discussed, one of the first questions to be asked is: how can it be enforced? After all, if the code is not enforced in any way then, it is argued, who is it benefiting? There is no straightforward answer to the question of how to enforce such a code, or even if it should be enforced, rather than be voluntary.

One suggestion is that the code be enforced by an independent, professional organization, such as the ACM, AITP, or PASS. Anyone who fails to follow the established code of conduct could have their membership of the organization revoked. On the assumption that most businesses would regard membership of the organization a key requirement in their hiring process, then it could, in theory, prove an effective deterrent to malpractice.

Again, any DBA who fails
to follow the established
code could have their
certification rescinded.

Another suggestion is that organizations that offer DBA certifications, such as Microsoft, should enforce some code of conduct. Again, any DBA who fails to follow the established code could have their certification rescinded. Obviously, this would only be an effective measure for organizations that require certification as part of their terms of employment. On the other hand, if Microsoft were to attempt this, what about the Oracle and MySQL DBAs? Would they need a separate code that is tied to their certifications?

Another option is to have a DBA Code of Conduct enforced on a per-organization basis. After all, many organizations already require their employers to abide by a "code of conduct," often in the form of an employee handbook. Such a code could be expanded to incorporate conduct specific to DBAs. On the other hand, if a company creates a separate code of conduct for DBAs, wouldn't it also have to create different codes of conducts for other job titles? Again, this is not a great solution.

In light of the numerous complications of implementing and enforcing a DBA's Code of Conduct, I suggest that following such a code, or not, is a personal choice on behalf of the individual DBA. As I noted earlier, I regard such as code as being primarily educational in nature, with the rewards for following it being a successful, rewarding, long-term, and satisfying career as a DBA. For those who choose not to follow it, well, who knows how their career will turn out? They might get lucky and survive over the long haul, but I doubt if they will ever fall into the Exceptional DBA category.

The Exceptional DBA's Code of Conduct

This section contains my suggestions for the core items that should comprise "The Exceptional DBA's Code of Conduct". My focus is on providing general guidelines that will help any DBA become more successful in their career.

I won't be so presumptuous as to imply that these guidelines are ideal or exhaustive, but they should hopefully get you thinking and be useful as a guide to you in your role as a DBA.

Protection and Disclosure of Data

  1. DBAs shall never intentionally do anything that contributes to the corruption or loss of an organization's data. While this should be a no-brainer, I am including the obvious, just to cover all the bases.
  2. Above all else, the DBA is the guardian, or protector, of an organization's data. The responsibilities of the DBA in this regard include but are not limited to:
    • Preventing data corruption (from applications, hardware, and people).
    • Provide high data availability, as defined by the organization's policy. Develop, and regularly test, a disaster recovery plan to minimize unexpected downtime, as defined by the organization's policy.
  3. DBAs shall take all reasonable precautions to ensure that changes to a production server have no detrimental consequences. All proposed changes should be thoroughly tested on a test server prior to deployment to production.
  4. DBAs shall proactively take all the necessary steps to ensure that data can only be accessed by authorized users. This may include, but is not limited to: SQL Server security, Windows Authentication security, encryption, SQL injection attack prevention, auditing, or other such security policies, as defined by their organization.
  5. DBAs generally have full access to all the data in a database. This presents two important points:
    • DBAs shall only view data in a database if they need to access it to perform their job duties. For example, a DBA may need to access data to optimize a query or create a report. But if the DBA doesn't need to access and view data for job-related tasks, then DBAs shall not snoop through the data for the sake of viewing it.
    • If, through the course of their required job duties, DBAs do view confidential data, DBAs shall not share any sensitive or confidential information with any unauthorized users.
  6. DBAs shall provide full cooperation with both inside and outside audits, providing truthful and factual information
  7. If the DBA learns that contractors, co-workers, or managers are making poor choices that could negatively affect the integrity or security of the organization's data, then the DBA should notify the appropriate persons within their organization.
  8. If a DBA discovers misuse of an organization's data, then the DBA should report this behavior to the appropriate persons within their organization.
  9. The DBA should maintain proper and complete documentation for all servers and processes for which he or she is responsible. The documentation should be of a form and standard that will allow a qualified peer to undertake the task, in the DBA's absence. The DBA should never protect (hide) information from their organization that would prevent another person from easily taking over his or her position, should the need arise.

DBAs and the Law

  1. Often, the data under the care of a DBA is subject to laws and regulations of one or more governing bodies. The DBA shall become familiar with these laws and regulations, and adhere to them.
  2. The DBA shall enforce all software licensing agreement with vendors, and notify the proper people in the organization if any breech is discovered.
  3. If the DBA becomes aware of illegal activity within their organization, the DBA shall notify the proper people in their organization, or the appropriate law enforcement agency.

Dealing With Third-Parties

  1. DBAs shall not accept gifts or favors from vendors if the purpose of the gift or favor is to influence, or to reward, the DBA's choice of purchasing goods and services from the vendor. More specifically:
    • The DBA shall proactively learn their organization's policies about gifts, so they know what they can or cannot accept. For example, company policy might allow a vendor to take a DBA to dinner, or to receive a free gift at a conference or a user's group meeting. On the other hand, an organization's policy might limit the amount of the gift to a maximum value, such as $50.00.
    • The acceptance of a gift, even if allowed by the organization, should not influence the behavior of the DBA in regards to potential purchase of the vendor's products and services.
    • Whenever a DBA purchases, or influences the purchase of goods or services, the DBA should only purchase those good or services because they are the ones that best meet the needs of the organization.

General Conduct

  1. The DBA shall conduct himself, or herself, professionally in all relationships with the people they deal with on a daily basis, including managers, co-workers, vendors, and their "internal customers." Favoritism and discrimination of any sort is to be avoided.
  2. If a DBA makes a mistake, and all DBAs make a mistake at one time or another, the mistake should be fixed as soon as is practical, and the DBA should inform everyone who might be negatively affected by the mistake as soon as possible. In addition:
    • Mistakes should never be covered up.
    • DBAs should take full responsibility for all their decisions.
  3. If a DBA has management responsibilities, the DBA should mentor those who need help accomplishing their objectives, and allow those with experience and enthusiasm to succeed and flourish within the environment he or she provides for them.
  4. The DBA will do their job to the best of his or her ability, developing and implementing best practices as appropriate, to help ensure the smooth and successful operations of the organization's databases.
  5. IT technology changes quickly. It is the responsibility of the DBA to proactively keep up on all technical areas that directly affect his or her job.
  6. If the DBA has agreed to a SLA (Service Level Agreement) for the servers under their care, then they will abide by those agreements. If they are not technically able to abide by the agreed upon SLA (for whatever reason), the DBA needs to contact the SLA owner and work out how to resolve the problem.
  7. Occasionally, the DBA may find that there is no established policy with regard to a particular aspect of their duties. For example, perhaps an organization doesn't have a policy that defines the desired level of uptime, or that defines who can access what data. In areas where policies should be established (to ensure the protection and integrity of the organization's data), but are not established, the DBA shall proactively identify the areas of need, make recommendations, and present them to the organization's management so they can make appropriate decisions.

It is impossible to provide advice to guide a DBA through every aspect of their duties and responsibilities as a DBA, and there are many "grey areas". What does the DBA do when they notify the appropriate persons of an important issue that could negatively impact the organization's data, and no action is taken to rectify the issue? Where do a DBA's responsibilities end with regard to uncovering illegal activity within an organization? What does a DBA do when a cost-cutting measure means they feel they can't fully adhere to their own code of conduct? These are all difficult question for any employee, not just a DBA.

If you, as a DBA, feel "pressured" to do something you are uncomfortable doing, then the best advice I can give is to talk to people. In most cases, the first step is to tell your manager, co-worker, project manager, or whoever is causing the problem, that you feel uncomfortable with their request, action or inaction, and explain why. If they don't want to listen, your next option is to escalate the issue to their manager. You may, or may not, receive management support for your case. If not, then you have to decide to "give in," or to find another job.

The key thing is that the DBA needs to keep cool and not take any rash action. Before making an important decision that could potentially hurt your career, talk over the issue with people you trust in order to get their feedback and input. Only take action once you have clearly and thoughtfully considered the consequences of your choices. This might mean keeping quiet and not making trouble, escalating the issue to higher levels of management, reporting a crime to an enforcement agency, or finding a new job.

Summary

My goal in suggesting an "Exceptional DBA's Code of Conduct" is to provide advice and guidance for those DBAs wanting to learn more about what it takes to become an Exceptional DBA. Is the code complete or perfect? Of course not. Consider it a working, educational document; it is certainly not intended to be an absolute set of rules that every DBA must always follow.

My hope is that it serves as a useful guide to the DBAs looking to navigate the "grey areas" and as a foundation for all those entering the profession with ambitions to become Exceptional DBAs.



This article has been viewed 4430 times.
Brad McGehee

Author profile: Brad McGehee

Brad is an Industry speaker, writer, and consultant on Microsoft SQL Server, specializing in SQL Server performance tuning, clustering, and high availability. He is the founder of www.SQL-Server-Performance.Com, and oversaw its growth to 350,000 visits each month. He is now Director of DBA Education at Red Gate Software. Brad is a frequent speaker at SQL PASS, SQL Connections, SQL Server user groups, and other industry seminars, and he is the author or co-author of more than 12 technical books and over 100 published articles. He spends what time he has left with his family in Hawaii. He is a Microsoft SQL Server MVP, MCSE+I, MCSD, MCT See also ...

Search for other articles by Brad McGehee

Rate this article:   Avg rating: from a total of 25 votes.


Poor

OK

Good

Great

Must read
 
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: One hundred percent with you on this one
Posted by: Hugo Shebbeare (not signed in)
Posted on: Thursday, September 03, 2009 at 10:04 PM
Message: But...as someone who is spending over a year already trying to defend Canadian Sox law, and the its non-enforcement within a public institution - which has written much of the above in their own Code of Ethics and does nothing to enforce it, how do we proceed? Are we to become Justices of the Peace because of our responsibility(?), and even so, given the years of understanding it takes to know the importance of being a Data Steward, what organisation will recognise this authority instead of the usual bureaucratic juggernought's tendency to sweep it under the rug. Would you be willing to sacrifice 18 months of your life to implement the above within one of the largest institutions in your country? These hardships will definately go unrecognised unless you bring them to the public eye, by some serious work with journalists and politicians, needless to say - but again, the good deed shall go punished at one point surely.
Thanks for the explicit professional details, another link to forward to the exec.s who think we are simply technicians :)

Subject: Licensing Agreements
Posted by: timothyawiseman@gmail.com (view profile)
Posted on: Friday, September 04, 2009 at 3:52 PM
Message: An excellent outline for an exceptional DBA's conduct, though I have questions about one point:

The DBA shall enforce all software licensing agreement with vendors, and notify the proper people in the organization if any breech is discovered.

Certainly a DBA should never knowingly violate a software licensing agreement, but I think in most organizations enforcement of it is well outside their domain of concern or control.

At least in organizations I have seen closely, that is (and should be) in the domain of others such as a systems administrator who manages such general details, a security manager, compliance officer, etc. It is in general much more of an administrative/business function than it is for a technical DBA.

In fact, for large organizations which may have large and even customized software contracts having a lawyer involved in that task might not be a bad idea.

Subject: Whistle blowing policies?
Posted by: jrbarnett (view profile)
Posted on: Saturday, September 05, 2009 at 10:29 AM
Message: Many organisations have "whistle blowing policies" that outline what action a staff member (regardless of what she/he does) should take if evidence of malpractise is uncovered within their organisation. This should always be the first action taken if malpractise is uncovered within the organisation.
I would consider adding this in where appropriate.

Subject: DBA
Posted by: Anonymous (not signed in)
Posted on: Sunday, September 06, 2009 at 5:35 AM
Message: What is a DBA ?

Subject: Codes
Posted by: Biz (not signed in)
Posted on: Monday, September 07, 2009 at 9:48 PM
Message: Hi Brad,
I am really a great fan of you and your articles are really great. Always your article used to give some new thoughts and points. But though this one is good, I couldnt find any new thoughts and i think it became moew general. I was expecting some specific code of conduct from you.
Hopeing to see you in person at code camp.
Bismi.

Subject: LOPSA / SAGE
Posted by: Peter (not signed in)
Posted on: Monday, September 07, 2009 at 10:30 PM
Message: You may want to take a quick peek at the "System Administrator's Code of Ethics", published as a join endeavor between USENIX, LOPSA and SAGE.

It covers a lot of your points in general terms (i.e. it can be applied equally to a network administrator or a DBA or a security administrator)... it's the Code of Ethics that I have posted on my walls, and it's been more than acceptable to anyone who's ever read it.

Subject: Good idea...
Posted by: Anonymous (not signed in)
Posted on: Monday, September 07, 2009 at 10:57 PM
Message: Now we just need one for developers...

Subject: spliting the data file and log file without effecting the performance.
Posted by: srinivas.b19 (view profile)
Posted on: Wednesday, September 16, 2009 at 5:03 AM
Message: Hi Team,

First I would like to say thanks for your help.

My requerment is I have a 200 GB data file, I want to distribute that 200 GB for 4 (K,L,M,N) drives for the performaoce.I don't want to create the new database and back\restore. so pleasehelp me .without effecting the performance and tabel structer also.

This task I need to do on production server.

Thanks,
Sreenivas.

 










Phil Factor
Finding Stuff in SQL Server Database DDL
 You'd have thought that nothing would be easier than using SQL Server Management Studio (SSMS) for searching... Read more...



 View the blog
Implementing User-Defined Hierarchies in SQL Server Analysis Services
 To be able to drill into multidimensional cube data at several levels, you must implement all of the... Read more...

Using the Filtering API with the SQL Comparison SDK
 Red Gate's SQL Comparison SDK provides a means to compare and synchronize database schemas and data... Read more...

SQL Toolbelt 2008: Predominantly an Engineering Task
 The conversion of the Red-Gate tools to be compatible with SQL Server 2008 might not seem, on first... Read more...

SQL Response: The dim sum interview
 Richard Morris met David and Nigel of the SQL Response team, in a dim sum Restaurant in Cambridge. They... Read more...

Writing Efficient SQL: Set-Based Speed Phreakery
 Phil Factor's SQL Speed Phreak challenge is an event where coders battle to produce the fastest code to... Read more...

Beginning SQL Server 2005 Reporting Services Part 1
 Steve Joubert begins an in-depth tour of SQL Server 2005 Reporting Services with a step-by-step guide... Read more...

Ten Common Database Design Mistakes
 Database design and implementation is the cornerstone of any data centric project (read 99.9% of... Read more...

Beginning SQL Server 2005 Reporting Services Part 2
 Continuing his in-depth tour of SQL Server 2005 Reporting Services, Steve Joubert demonstrates the most... Read more...

SQL Server Full Text Search Language Features
 SQL Full-text Search (SQL FTS) is an optional component of SQL Server 7 and later, which allows fast... Read more...

Creating CSV Files Using BCP and Stored Procedures
 Nigel Rivett demonstrates some core techniques for extracting SQL Server data into CSV files, focussing... Read more...

Over 150,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.

Join Simple Talk