Join | Login | Why Join?   
SQL Server, Oracle, DB2, Sybase, MySQL Help - SSWUG.ORG HACKER SAFE certified sites prevent over 99.9% of hacker crime.
Search SSWUG:   
 
Access to 555 free guest articles, discussions and more, just create your free SSWUG User ID:
Email address:  
This will be your login ID - we'll email you your password - you'll even receive the newsletter, opt-out at any time.
Email to Friend //  Discuss Article //  Rate Article //  Digg Article //  Add to Del.icio.us //  Add to Technorati


(Please be sure to vote on and rate this article)

A DBA Code of Ethics
by Stephen Wynkoop & the SSWUG.ORG Community

To get started with the code of ethics that has been thrown around on the newsletter for quite a bit, we need to start with an outline of what we're really trying to accomplish.  I'd really like to see the code of ethics be high-level things - things that a DBA should be expected to do, ways that a DBA should be expected to act and so-forth. 

From there, it would be my hope that we could draw direct relationships between those ideals and the tasks that fulfill them - in a perfect world, I'd love to see it where the code of ethics was linked to tasks that would be part of a given bullet item/objective on the code.  If we can get to that point as a community, we'll really end up with a Code of Ethics that DBAs can work against, and then the particular approaches to working with databases that support those.

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.

Probably a decent start to getting the discussions flowing.  What's next? 

- Email me, let me know...
   - What's missing?
   - What's here that shouldn't be?
   - Does it need to be specific to a position (see next section)?

Will It Work?
A number of people wrote in indicating that it wouldn't work to have or put together a code of ethics for a number of reasons.  One was the fact that people can't agree even on what a DBA is - or a Data Analyst - or even defining junior / senior DBA responsibilities.  More wrote in saying that it was something that could be defined and put together, but where's the "enforcement?"

I don't think that's what it's all about - enforcement.  I think it's about striving to be a more cohesive profession when it comes to what it is we do, how we do it and what reasonable expectations are for how we'll go about it.  That's what I hope this will accomplish.  If we truly get a collective bit of input and talk through what should be here, it can be a solid measuring stick for getting this type of responsibilities document together.

For those wondering, this document is, and will remain, free.  It's not a members-only document.  While you have to be a member to vote on it with our systems, you don't have to be a member to link to it, talk about it, email me about it, participate in building it.  This needs to be as broad an effort as possible.

The link to this document is http://www.sswug.org/see/28506


PLEASE BE SURE TO VOTE

It's very important to the author to know what you think of the article!

 Related Articles - For Members.
All Articles By Author

Second Normal Form (2NF)
Use a CRC Function to Compute a Reproduceable Key
The Ever-Morphing Role of the Developer/DBA
First Normal Form (1NF)
Moving to DB2 9: Considerations and Migration
XML Data Islands - What are they?
Retrofitting Table Level Delete/Archive Strategies - Short Term Storage Models
System Development and design, a Concern of Organization



Key (Please note):
(R) - registration may be required for access at the target site
($) - target site may require paid membership for access to this or other content


No Comments/Feedback Posted Yet. Post Your Comments/Feedback

Email to Friend //  Discuss Article //  Rate Article //  Digg Article //  Add to Del.icio.us //  Add to Technorati

   




 

[ Register ] [ Webcasts ] [ Podcasts ] [ Newsletter Archive ] [ RSS/Feeds ]
[ About ] [ Advertise ] [ Contact ] [ Privacy ] [ Terms of Service ]
[ Link to SSWUG ] [ List Server Archives ] [ Recent Orig. Content ]
(c) 1997-2009, Bits on the Wire, Inc.  (0)

Some names and products covered by SSWUG are the registered trademarks of their respective owners.
DAA10354WWW004