Saturday, June 16, 2007

Is Database Administration for Suckers?

Tim DiChiara over at Eye On Oracle has a post titled "Database Administration is for suckers" where one of his reader posted their disillusion with being a DBA. Stephen G, the DBA in question, basically complains about being a DBA and the bad hours (on standby, lack of appreciation, excess hours, etc) that comes with it. He went on to say that if he has the opportunity to start all over again, he would rather be an accountant or a lawyer instead.

Predictably, there was a ton of comments with folks agreeing and disagreeing with Stephen G's assessments. I think it is how you approach your job/career. If you are looking at making big dollars with minimum hours, well, those are far and few between that those who got it are not going to give it up.

Me, I operate from a few principles which I think applies to this situation and I think it is true for all kinds of jobs. These principles includes:
  • doing the best job that you can with pride;
  • enjoy your work;
  • be learning; and
  • work yourself out of the job.
I think the last one probably warrants an explanation than the first three as they are pretty self-explanatory. Most people goes "Huh? Why would you do that?" when I told them of the last principle mentioned. Most good consultants do that as a principle, they cross-train and transition over to the employees so that they can leave for their next assignment. Employees should similarily be doing the same. By doing so, you are freeing up your time to enable you to focus on the advanced & strategic tasks. In this way, you can work yourself to a better position bringing more value to the organization.

If you don't and only work to ensure that you are the only one who knows the systems/applications or whatever that you do thinking that you have just ensured "job security". Well, you haven't as you have now put yourself in a position where you have become a liability to the organization. How are you going to be able to take time off your job for training, vacation, etc? The organization is now at risk if you leave or if something happens to you so the logical thing for management to do is to cross-train someone else to learn about the system. The purpose of this cross-training is not to free you up for the more advanced and strategic tasks but rather it is to insure the organization against losing you whether deliberately (you leaving for greener pastures) or accidentally (you getting hit by a bus).

Getting back to Stephen G, each person have choices and the fact that he stuck around for 20 years in the same career say something but if you are not happy with your current work situation, then my suggestion is that you do something about it (i.e. either work to change the job or go somewhere else). Easier said than done, I know but again it is about choices. Remember that you spent roughly a third of your day at work so it is in your best interest and health to ensure that you enjoy the work and the people that you work with.

Saturday, June 09, 2007

Interviews again or why they aren't useless

I blogged briefly about my organization looking for contract DBAs and interviewing candidates and recently Eddie Awad spoke about "Why resumes are useless" and reference Andrew Wulf's "The Stupidity of Interviews". Both blog entries received a fair amount of comments from folks who largely concurred with Andrew's assessment. I would agreed that resumes/interviews are not prefect and is a "hit & miss" way of identifying suitable and qualified candidates. I wouldn't classify them to be useless though as the "success" of the resume/interview process actually depends on how it is being handled and managed.

For example, if your organization has a dedicated HR department who vetts resumes and forward those which seems to meet the qualifications listed to the hiring manager basically means that if the candidate do not make an effort to highlight and identify where s/he meets the position qualifications, then s/he can't blame anyone but themselves for not taking the effort to "customize" their resumes. Eddie mentioned this as a negative about resumes being made to order. I would rather see that the candidate has taken the time to do so although if the only "customization" was to prefix the resume name with the hiring organization, then that isn't customization but rather an indicator. I've seen resumes from folks who don't qualify but they sent in their resumes anyway. As an example, I'd seen a resume from someone who has no IT background nor training but they submitted their resume for an IT position. It would be okay if the position indicated that it was a trainee-level and the organization is willing to invest to train the successful candidate BUT not if one of the qualifications are "years of experience in a similar position".

Andrew Wulf wrote "Resumes seem to be mostly useless, virtually no one actually reads them before the interview and they seem mostly not believed. In this way resumes become a kind of worm to dangle in front of the recruiter or HR fish, just enough to hook some interest, but are discarded afterwards. The actual contents are expected to be padded or invented so they may as well just say "DUDE KNOWS CODE".

I do and I actually tried to match up what was summarized in the cover letter or the first page to ensure that we are on the same page as to the candidate's experience. I've seen resumes from OCP candidates who don't have any work experience and resumes from DBAs who have been working in their field for the last 15 years but when you dived into the details of their resume, you quickly realized that 10 of those years were spent on basic operational stuff like create a new database, create users, ensure that backups are done (usually via Export) but no experience in the more advanced stuff like recovering databases due to corruption, cloning, securing databases, etc. I totally agree that it is very difficult to tell from the resume whether the candidate is what they say they are and hence the need for an interview or a series of interviews. Depending on the level of the position, I would say that have 5 interviews for a programmer is probably an overkill but 5 for a senior executive level is not. A friend of mine got interviewed for a senior Excutive position and the whole process took 6 months and a number of interviews. He told me that he ended meeting all the Executives before a decision was rendered.

Andrew also wrote about how he wished that candidates (for programming positions) would bring in something they wrote. I would say that "Yeah, go for it" and ask the candidate to do so when arranging for the interview time. The good candidates comes prepared with samples of deliverables of projects that they have been involved previously keeping in mind to not violate any confidentaility agreements and/or disclosure.

Depending on who does the interviews (and I am assuming that it would be the hiring manager plus at least a co-worker), it is often necessary to structure the interview into two or more sections. There are no particular order but the sections should include (a) section to validate technical skills and knowledge; (b) section to identify required "soft skills" and experience. The technical skills validation is pretty self-explanatory but the other section would include things like communications, teamwork, work habits, approaches and philosophy to type of position. This is not easy to explain in writing but basically you want to ensure that the candidate will be a good/great fit for the organization taking into consideration the corporate culture, the kind of team that needed to be build and the gaps that you have. It's like building a sports team as you might not want to have several prima divas on the team who might fracture the team into various camps but you want a team who can work well together and are committed to achieve common goals. You should and could also include assessment of the candidate's potential too and how you would approach that is totally up to the interviewer.

In a nutshell, the interview/hiring process is a "dating ritual" to see if there is chemistry and fit between the organization and the candidate. In closing, I wish the best of luck to those who are currently seeking employment and for those who are considering moving, ask yourselves whether you are leaving for the right reasons and if so, best of luck in your search. As they say, "The best time to look for employment is when you are employed" as this way, you can evaluate the organization and be prepared to turn them down if the organization does not seems to be a good fit.

Wednesday, June 06, 2007

Oracle & Acronyms

I attended a one-day workshop (hands-on lab) at the local Oracle office here in Vancouver today learning about Oracle RAC and try some hands-on labs to install, configure and maintain a RAC environment. One of the things that struck me was how many acronyms were being used in this one-day workshop.

RAC = Real Application Clusters
FaN = Failover Application Notification
ASM = Automated Storage Management
TAF = Transparent Application Failover
OCR = Oracle Cluster Registry
OUI = Oracle Universal Installer
VNC = Virtual Network Computing
CRS = Cluster Ready Services
CRSD = Cluster Ready Services Daemon
CSS = Cluster Synchronization Services
VIP = Virtual Internet Protocol
GSD = Global Single Database
ONS = Oracle Notification Server
EVM = Event Manager
RDBMS = Relational Database Management System
JVM = Java Virtual Machine
OLAP = Online Analytic Processing
HTML = Hyper Text Markup Language
SID = System Identifier
GUI = Graphical User Interface
OCI = Oracle Call Interface
JDBC = Java Database Connector
CPU = Central Processor Unit
DBA = Database Administrator
OS = Operating System
Gb = Gigabyte
Mb = Megabyte
URL = Uniform Resource Locator
EM or OEM = Enterprise Manager or Oracle Enterprise Manager
SQL = Structured Query Language
CRM = Customer Relationship Management
DBCA = Database Configuration Assistant
SSH = Secured Shell

Phew! I'm sure that there are more that I either missed or have taken for granted. No wonder the business folks in our organizations look at us IT geeks with glazed eyes.

Oh, although the one-day workshop does not delved into a lot of details, it does give me a good overview and concept of how the whole thing should work and it does take me away from the office which allows me to focus on the subject at hand. Now, only if I can find the time to play around with it more on either my home PC or/and laptop.

Monday, June 04, 2007

Moving on...

I have been with my current employer since August 2004 and originally I was hired as the Data Architect but unfortunately I did not end up doing any data architecture work. Almost immediately I was given the DBA team (2 DBAs) to manage and that grew to 3 before the end of the year. Most of my time was spent on assessing and managing the team plus the database environments. In fact, approximately 60% of the time was spent managing one particular employee who thankfully was no longer with us and the rest was trying to educate and impress on the team for good DBA practices like keeping current with releases, patches and fixes, planning and scripting typical tasks, etc. Currently the team includes 3 DBAs (2 senior and 1 intermediate) and 2 Unix Administrators and we are looking to expand by an additional 3 senior DBAs (2 contract and 1 permanent). Why the growth? A couple of reasons; my employer has bought into the Oracle technologies (RDBMS, Application servers and Applications) and the role of the DBA is evolving into the Application area (i.e. Application DBA). We have also in the tail end of completely separting our Production environment from our Non-Production environments and eventually the DBA group will focus on more of a Development DBA role with second tier for Operational DBA (most typical Operational tasks will transition over to our Operations group who should be able to do the typical create user, reset password stuff via OEM).

Anyhow I am moving on as I have recently "won" the Manager of Application Services position within the IS Department. "Won" as in competing with other applicants/candidates (both internal and external) for the position which has been vacant since July of last year. There are a number of challenges for the Application Services group. One will involve a reorganization of the current Application Services group to better position ourselves to support the Oracle technologies stack as we have gone wholesale with Oracle. I will still try and keep current with the Oracle RDBMS but I suspect that I would be spending more time with Oracle Application Server, Oracle Applications, BPEL Process Manager and possibly JDeveloper.

The trick now is to ensure that I can transition off my current position and the project work that I'm currently working on to someone else so that I can focus on my new position and the various challenges there.