October 7, 2008 at 9:49 am
Should the DBA team exist on the "infrastructure" side of the IT organization, the "application" side, or should there be a direct line from a "Data" Organization to the CIO/CTO that essentially sits between the Application and Infrastructure roles?
It's a common battle, I'm sure...Just wondering what others do and what works and doesn't work.
October 7, 2008 at 11:11 am
Where I work we have the 2 sets of DBA's
The production DBA's sit on the application team and they handle the production and QA servers.
The other set of DBA's sit with the developers and handle the Development servers.
October 7, 2008 at 11:38 am
greggoble2 (10/7/2008)
Where I work we have the 2 sets of DBA'sThe production DBA's sit on the application team and they handle the production and QA servers.
The other set of DBA's sit with the developers and handle the Development servers.
Interesting...Do both sets of DBAs do the Infrastructure work for their respective environments?
October 7, 2008 at 12:34 pm
Our infrastructure team is separate from the application side, in a sense. They're responsible for procuring/repairing hardware and all other network needs, getting everything ready for the applications part of things, where I sit. I handle all the databases and servers AND assist the developers when needed. Of course, I'm the only MSSQL DBA in-house. 😉
-- You can't be late until you show up.
October 7, 2008 at 12:44 pm
I always vote to have the group placed under the best manager from the choices available. That way if you get a bad one you can then make the argument for the team to move. You should be able to use this at least a couple of times before the CIO / CTO catches on, unless you have a good one of those and he / she might get it right away. 😛
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
October 7, 2008 at 12:52 pm
I've seen it multiple ways. Typically when there are two teams, usually larger environments, the production people do the infrastructure everywhere. That keeps environments coordinated and ensures the dev guys don't change things and forget they did it. Easy to have them ask for the change.
Course the prod people need to respond quickly.
It's good to rotate people in and out of the groups as well, let them get a feel for how things work on the other side.
October 7, 2008 at 1:06 pm
We've done it both ways where I work. Initially, our data management group, which does data analysis and database management, was part of the infrastructure team along with network and server admins. For the past 5 years or so, we've reported to a development manager.
We've reported directly to the CIO for a couple of brief periods (3-8 months) when a manager has left and hasn't been replaced right away.
The reasoning for us being in the development area is we work directly with developers, although we also work with Network Services when working on servers.
Greg
October 7, 2008 at 2:55 pm
At my company the production dba will do the infrastructure with help from the sys admins meaning they will rack, cable, partition the disks and install the OS. Then once the server is "handed off" from the sys admins, the prod dba will install sql and set all the configurables and hand it off to the dev dba.
Many pros and cons though.
October 8, 2008 at 2:05 am
We support both development and production systems/users. In our company we sit in the production (infrastructure) area but have moved between various areas over the years. I think in an ideal world we would have two teams - one for dev and one for production and then it would be clearer where we should sit. The work we do doesn't really fit in with the rest of the infrastructure team.
October 8, 2008 at 6:42 am
I find the concept of "production" dbas and "non-production" dbas to be an interesting concept, but one that I don't like if I'm being honest. I think it is vital to ensure that the production environments are maintained, configured, and controlled in an identical fashion to their non-production environments. I realize that people probably put their senior people in the Production role and perhaps less senior people in the non-production role...But...Along with ensuring that the environments are maintained in a consistent manner, I think it is vital to have a single primary support person for a specific database in support of a specific application. That way, anytime the Dev/Test environment is modified the DBA responsible for that specific database environment can see the effects of that change through each environment change as it is rolled out. Consistency, consistency, consistency.
It also sounds like a lot of companies continually change their reporting structures, which makes sense since the DBA function straddles the Application and Infrastructure domains.
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...
October 8, 2008 at 7:02 am
SOX tends to require separation of dutires, so having someone handle the infrastructure makes sense. The problem is you have multiple parts (network, OS, DB, app) and often that means 2-3 people.
I'm not sure you need a director unless you have lots of people in that environment that already have managers. If you have 2 network people, 3 sysadmins, and a DBA to handle your infrastructure (really production), then maybe a manager.
To me, everything is production. The Dev environments are like part of our factories in years past. They matter and should be controlled, not to slow things down or prevent change, but to ensure that each changes is known, documented, and propagated through to QA and Live (production customers use) in the same way.
October 8, 2008 at 9:26 am
Steve Jones - Editor (10/8/2008)
SOX tends to require separation of dutires, so having someone handle the infrastructure makes sense. The problem is you have multiple parts (network, OS, DB, app) and often that means 2-3 people.I'm not sure you need a director unless you have lots of people in that environment that already have managers. If you have 2 network people, 3 sysadmins, and a DBA to handle your infrastructure (really production), then maybe a manager.
To me, everything is production. The Dev environments are like part of our factories in years past. They matter and should be controlled, not to slow things down or prevent change, but to ensure that each changes is known, documented, and propagated through to QA and Live (production customers use) in the same way.
We have separet server and network teams that are separate from the DBA team and report up through the Director of Infrastructure. The Director of Data would have the DBAs, ETL coders, Datawarehouse, and Integration (Middleware layer). The DoD would be the one person that controls where all the data is and how it is used, etc...
October 11, 2008 at 12:07 pm
:w00t:
CIO
|___ PMO
|
|___ Infrastructure
| |
| |___ Systems
| |___ Networking
| |___ Site Support
|
|___ Application Group "n"
| |
| |___ Functional Analyist
| |___ Programmers
|
|___ DBA Team
| |
| |___ Production Support
| |___ Data Warehouse Architect
| |___ App Design/Development
|
|___ Q/A
|
|___ Change Control
|
|___ Help Desk
😉
_____________________________________
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 11, 2008 at 2:47 pm
PaulB (10/11/2008)
:w00t:CIO
|___ PMO
|
|___ Infrastructure
| |
| |___ Systems
| |___ Networking
| |___ Site Support
|
|___ Application Group "n"
| |
| |___ Functional Analyist
| |___ Programmers
|
|___ DBA Team
| |
| |___ Production Support
| |___ Data Warehouse Architect
| |___ App Design/Development
|
|___ Q/A
|
|___ Change Control
|
|___ Help Desk
😉
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...
October 11, 2008 at 8:17 pm
Mike (10/11/2008)
PaulB (10/11/2008)
:w00t:CIO
|___ PMO
|
|___ Infrastructure
| |
| |___ Systems
| |___ Networking
| |___ Site Support
|
|___ Application Group "n"
| |
| |___ Functional Analyist
| |___ Programmers
|
|___ DBA Team
| |
| |___ Production Support
| |___ Data Warehouse Architect
| |___ App Design/Development
|
|___ Q/A
|
|___ Change Control
|
|___ Help Desk
😉
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...
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
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 33 total)
You must be logged in to reply to this topic. Login to reply