October 12, 2008 at 2:01 am
Jeff Moden (10/11/2008)Nope... for a decent size company, that's about what I'd expect except it might be missing the "Project Management" layer.
For some of the small companies I've worked for, the org chart was really easy... 🙂
CEO
|__Me
Project Management is hidding into PMO -Program Management Office
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 12, 2008 at 2:47 am
Mike (10/11/2008)
Isn't that too many direct reports to the CIO? I assume that the "n" means many application teams...Even if there's only one application team, that's still 7 direct reports...
Not really. Look at the President and his Cabinet, how many direct reports do you have there?
If the President can handle it my CIO also can 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 12, 2008 at 9:14 am
PaulB (10/12/2008)
Jeff Moden (10/11/2008)Nope... for a decent size company, that's about what I'd expect except it might be missing the "Project Management" layer.
For some of the small companies I've worked for, the org chart was really easy... 🙂
CEO
|__Me
Project Management is hidding into PMO -Program Management Office
Heh... How true, how true... 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2008 at 8:19 am
But...Has anyone had a dedicated "Data" organization that reported directly to the CIO? What I find ironic about the CIO is that the title is "Chief Information Officer" and yet...The standard reporting structure obscures the CIOs ability to have a direct connection to a companies (arguably) most valuable asset.
Basically what I'm talking about is a Director of Infrastructure, a Director of Applications, and a Director of Data. This is something I have been pitching to our CIO for a while now and it looks like it is about to happen...
Our Data Warehouse group reported to Finance for quite awhile. This kind of got us out of the IT vs. Operations battle. The auditors seemed to like this - there was good separation of duties.
Greg E
October 14, 2008 at 9:30 am
In a previous job, I was a Server "Break/Fix" tech, and that meant performing backup monitoring (and changing backup tapes), monthly re-boots at oh-god hundred Sunday mornings, monitoring disk space usage, and installing the OS and any/all applications, including SQL Server, according to the "run book". Run books were submitted by the server's "Requester", and had to meet standards or the requester was required to get an exception. We, the server techs, were the guardian of the standards. We were not DBA's, and in fact, the DBA role for SQL Server didn't really exist in that company, yet for mainframe DB2, it did, so the application folks performed those tasks. Not exactly the best way to go, but then, the auditors had trouble with the idea of a special LAN ID that we each had that had admin rights on ALL servers, despite the necessity thereof, given the expectations on what we needed to be able to do. Of course, handing over build tasks to application teams meant tossing standards out the window, so go figure.
Steve
(aka smunson)
:):):)
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 14, 2008 at 9:36 am
Interestingly enough, if you actually read the Operational Framework blueprint documents by Microsoft, the DBAs actually sit more in the "QA" area of the business.
October 15, 2008 at 9:57 am
The application developer should be the DBA of his applications' databases.
Separation of roles results in low quality results.
Integration is the route to high quality and efficiency.
October 15, 2008 at 10:35 am
doobya (10/15/2008)
The application developer should be the DBA of his applications' databases.Separation of roles results in low quality results.
Integration is the route to high quality and efficiency.
:w00t: my eyes!... my brain!... it hurts!!!
1- I can't even start to tell you how in disagreement I am with your first paragraph. A developer is a developer, a DBA is a DBA; most of the crappy databases you find out there got born following your line of thinking.
2- One more time, uterly in disagreement. Since the industrial revolution you know separation and specialization of roles is benefitial.
3- If for integration you mean integrating developers and DBAs in the development effort, I'm in agreement 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 15, 2008 at 10:50 am
Actually, you might NOT disagree, depending on what PaulB meant. One could interpret what he said as meaning that his reference to "should be the DBA", means that an app developer should be A (or THE) DBA, and in particular, the one for his applications databases.
If I had my way, an organization would NEVER have ANY developers who weren't capable of good, solid, DBA skills, at least from a performance and database design perspective, anyway. Applications will continue to be and act like the CRUD they usually are until such time as my premise is actually true.
Steve
(aka smunson)
:):):)
PaulB (10/15/2008)
doobya (10/15/2008)
The application developer should be the DBA of his applications' databases.Separation of roles results in low quality results.
Integration is the route to high quality and efficiency.
:w00t: my eyes!... my brain!... it hurts!!!
1- I can't even start to tell you how in disagreement I am with your first paragraph. A developer is a developer, a DBA is a DBA; most of the crappy databases you find out there got born following your line of thinking.
2- One more time, uterly in disagreement. Since the industrial revolution you know separation and specialization of roles is benefitial.
3- If for integration you mean integrating developers and DBAs in the development effort, I'm in agreement 😉
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 15, 2008 at 11:01 am
smunson (10/15/2008)If I had my way, an organization would NEVER have ANY developers who weren't capable of good, solid, DBA skills, at least from a performance and database design perspective, anyway.
Steve -- It looks you work for a very rich organization.
It takes about 10 years to train a capable, solid DBA with both performance tuning and design skills; most never get there and you end up having the "design guy" and the "performance guy" in your team surrounded by your "production support guys" and your "junior guys".
You want them to do the user interface too?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 15, 2008 at 11:33 am
when I design a application / database it is a balancing act between:
- performance
- manageability
- simplicity
- flexibility
- etc.
every table design decision has implications for views and stored procedures
every view design has implications for stored procedures
application requirements feed back into database design and vice versa
it is a complex set of push pull interactions with hierarchies of issues and priorities
the reason app/db development is a highly skilled job is the developers ability to design and code
bearing in mind so many different factors simultaneously
when I write application code I profile it as I write it - memory and performance
when I write a view I profile it / performance tune it as I write it - if I find a performance problem due to a table design decision
maybe I will redesign the tables - again considering the pros and cons of all the related changes
the point is I am thinking with ALL MY HEADS at the same time - I do not have to schedule a meeting or phone anybody
I can have a meeting between "Database Developer" "Database Administrator" "Software Engineer" "Systems Architect" in about 1 millisecond
Because they are all me.
As soon as you "dis-integrate" me into different people you are into a world of pain:
- interhuman communication is incredibly slow and prone to error
- multiple people find it hard to share the same perspective - especially if it is constantly changing
October 15, 2008 at 11:34 am
It takes 10 years for several reasons:
1.) Training is almost always completely inadequate, starting with the large number of incompetent college professors teaching the computer courses, and ending with corporate resistance to employees taking the allegedly EXPENSIVE courses from Microsoft, that are generally full-week courses and actually DO teach what's needed, provided the student is capable in the 1st place. So thus I ask, which costs more, an untrained DBA or the allegely expensive training?
2.) Managers: They are rarely former DBA's, and simply don't have the skills to judge which training is needed, nor do they usually know much beyond the idea that the computer systems are either working or broken.
3.) Intentional stupidity. Don't get me started, or I'll be here all day. It occurs at ALL levels, and usually due to poor hiring decisions.
Bottom line is, the CEO is ultimately responsible for ALL of these failures, and yet, when have you ever seen one take the fall for them?
As to me working for a "rich" organization ... nope, sorry, haven't EVER been there, but if things were done right, one wouldn't need to in the 1st place. Please recall that my comment was "IF" I had my way. Can't say I can recall ever having that in the corporate "distributed" computing world. (as opposed to mainframe)
And again, with the proper training, yes, any one of the team should be capable of designing a UI, as they should know the right questions to ask because of their DB design skills.
Steve
(aka smunson)
:):):)
PaulB (10/15/2008)
smunson (10/15/2008)If I had my way, an organization would NEVER have ANY developers who weren't capable of good, solid, DBA skills, at least from a performance and database design perspective, anyway.
Steve -- It looks you work for a very rich organization.
It takes about 10 years to train a capable, solid DBA with both performance tuning and design skills; most never get there and you end up having the "design guy" and the "performance guy" in your team surrounded by your "production support guys" and your "junior guys".
You want them to do the user interface too?
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 15, 2008 at 11:35 am
Interesting to know all kinds of setup with respect to assigning tasks for DBA's in batches. Well I am the only DBA for all environments but one positive thing is I have a Storage Admin who takes care of all the hardware stuff.
The bad part is everyone from Dev Team to the VP level ask are entitled to throw questions at me :crazy:
Huh..the DBA job, I like it though 😉
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
October 16, 2008 at 2:22 am
As a DBA with over 10 years experience, I have the correct answer.
:hehe:
The DBA should reside remotely, preferably in Aruba. Just keep the sand out of the laptop.
October 16, 2008 at 2:35 am
Steve --
Have you noticed that in a weird way you are supporting my position?
The parallel universe you are describing where college professors know what they are doing, upper management pays for all needed training, middle management knows what a DBA does and people are not stupid by nature... is unfortunatelly located at several degrees of separation of our universe.
So... bottom line is that it takes 10 years to properly train an elite DBA, the one comfortable doing Data modeling, Planning physical implementation and doing serious Performance tuning.
DBAs are the last line of defense, by the way... man the walls, look at the horizon, what you see? yes! a join developers/end-users force is marching one more time in your direction flying the colors of another crazy idea 😀
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply