I feel that DBAs belong in three IT areas : infrastructure, development, and security. DBAs in different depts specialize accordingly, but work together as a phantom department. If all of the DBAs are isolated to a single department they tend to cease truly being DBAs & act more like enforcerers against the other departments, often hurting the company instead of helping it.

Some DBAs, which Craig Mullins calls "system DBAs"
http://www.informit.com/articles/article.aspx?p=29321&seqNum=6
deal purely with infrastructure: backup, recovery, etc.

Others have broader scope that edges closer to the data modeling and data architecture realm supporting specific applications.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:14039738984108

"Since they cannot be in all three simultaneously - what makes this work"

I never said it would be the same person. In fact, it needs to be seperate people, each with a specialty.

"Why would the DBA team in the development group want to align themselves with the DBA team in security for example."
Without insight into security at the DBA level, you get things like TAPI with Public execute on the stored procs (& I know how you looove TAPI) or Public select on _every_ table in the DB (seen both at multiple companies with developer only DBAs...)

"Why would it matter that the person in the security group calls themselves a 'dba' - they are still someone in the security group - with no straight line management wise to the person in the development group."
Not calling themselves a DBA, being a DBA. They have all of the training, background, etc you would expect from a "basic" DBA _plus_ extra focus on issues such as authentication options (kerberos, SSL), centralized users and roles (OID), etc. These skills are typically waaaay outside a developer DBA's skillset that is more focused on how the app works in the database, or the infrastrucutre DBA who is more focused on the database's impact on a host or hosts (RAC) and network, backup, DR, etc.

Traditionally many companies take the "One DBA to rule them all" approach & slap them all in one department. This is 80's thinking & it was wrong then & is wrong now. Think of all of the data breaches that were caused by a DBA not securing something (most likely becuase they were developer DBAs) or speed complaints because the DBA is in infrastrucure and lacks the skills to analyze developer code for inefficencies, etc, etc, etc.

Yes they can all work for different departments and then still be members of an xtra departmental team with authority to make changes in each department, becuase each dept has a DBA on the team & that DBA is the one within the dept who ALREADY HAS THE AUTHORITY TO GET IT DONE.

Not doing it this way is just an invitation for a future disaster because some aspect was overlooked.

If the company is big enough to have seperate infrastructure and development departments, then wherever the DBAs currently reside, pick the other dept & find an existing canadate to pick up on DBA related tasks that are oriented towards that department. If you're lucky enough to already have an IT Security dept, most likely they're already doing some of this (centrialized management, encryption, advanced authentication, etc)

"I'll stick with DBA in the center - in development"

development is NOT the center. they are a piece of the company and only one piece. everyone in IT is not there for their own good, they are there to support an enviorment for the end user. the end users are the "center" of the company.

"the security team is setting standards"
but how can the security team
1) set standards without knowing the coding "style"?
2) enforce them without a DBA presense?
They interact, not dictate.

The TAPI was given as an example of a developer creating an insecure enviornment that was approved by a DBA as being OK. Because the DBA was in a development department, they didn't see an issue with the security. If this development task had been bounced off of a DBA not directly asscociated with the development department, it would most likely have been corrected early on in the software lifecycle. If it was just a DBA outside of development (say, in infrastructure. with no coding skills) then the developer could have taken the "but this is the way it has to be in order for it to work", which is of course not true.

A DBA, the single DBA, CONSTANTLY deploys insecure applications. Every company, everywhere. The shame is that they truly believe that everything is OK, until some diaster they could not forsee hits the company (say loss of unencrypted data backup tapes by the carrier) A security DBA free of development duties would have long ago focused on security issues and worked to prevent this (probably by working with the infra DBA to secure the backup in this example). Non-developer DBAs don't focus on the "make it run" only the "make it secure" or "how do we recover in DR", etc.

The security team should include developers, even if only as liasons & not team members. If a security dept doesn't interact with dev or infra departments, but simply sits on a hill and voices mandates, then they're just useless. How do they know their security decisions will not negatively impact dev or infra?

I have seen successfull security in enviornments without a security department, where the infra & dev both have had some training in basic security concepts. Enforcing Least Priv at the coding & infra levels goes a long, long way.

Rember that the majority of intentional data breaches are caused by staff. Who in the company has better access to sensitive data than developers? Who is most likely to have lax security on their machines? Developers are notorious for viewing all security with distain. Edicts sent from high to slow their progress. Make the developers part of the solution and this tantrum disappears.

But it doesn't matter what team name they call me, I'm pretty much worried about everything with the database. I've been called a developer, infrastructure support, application dba, physical dba, backup and recovery support specialist, etc. The point is, you have to know how the application works, what the hardware does, how the database is backed up, what the recovery options are...pretty much everything to be an effective employee who manages databases. I may not be directly responsible for an area, but I'm gonna know how it works and definitely speak up if something is not right. I would hope more have the same mindset.

Having been an Oracle DBA for 14 years, and having brought up the 19-member DBA team at one of the major corporations, I supppose I can share some perspectives on this. Initially, my DBA team was under the Datawarehouse technical team, simply becuase that was the first database outside of the mainframe in our company. We were with ETL developers, DW architects and report writers. It was interesting; but we got called in for every issue - the database design wasn't good, the growth wasn't predicted correctly, the qury by the report developer is slow - all these were somehow related to Oracle database. Since I was instrumental in bringing Oracle to our company, my team was naturally on the defensive.

Later we were moved to one application team, but modeling was stripped away from us. We supported everything from physical design to operational support for all apps; but one app team controlled us. Well, I am sure you predict what happened. The buggest heartburn was the developers ruled. Nothing they ever did was wrong; everything we ever did was just not enough. Someone ran a query with three table cartesian product from an application that was called 3 times a minute - was merely a ignorance issue. Developers were java people; so teaching them Oracle was our "responsbility" (while we committed to Oracle database; so we sort of missed the point why they can't learn a bit of SQL). But we did teach. Nothing happened. The worst 2.5 years of my career.

Landscape changed again. We underwent a row migration like operation to move to Infrastructure group, along with storage, system, etc, where the manager were primarily from systems side. Now nothing the systems and storage folks did were wrong; but everything DBAs did were wrong! So, now we got the flak from both sides - from our customers and our providers. And worse, the modeling group was under the Architecture. The DBA group appeared marooned in a vast ocean with lots of islands of cannibals.

Recent change - DBA group is a part of the applications group now - a full circle from where we started; but independent authority with reporting structure pretty well rooted with some real teeth and fangs to make rules and enforce them. This works out pretty well. Most of the issues emanate from app design and execution; so an integrated DBA/App team is probably the best shot at quality. But we collborate with the infrastructure folks like sysadmin and storage while design.

The morale of the story is that it does not matter where the DBA group is organizationally positioned. The issue is how much the organization understands the input by the DBAs and the value they bring to the table. As long those soft concepts are understood and the necessary authority structures are in place, it's immaterial where they are placed. The DBAs are probably in the unique position of spanning the entire gamut of app cycle - from design to operational support. This is unlike other groups. So, placement with any other group will be illogical anyway.

Just my $0.02 + tax and not expecting a bailout anytime soon.

"stick them in the DBA group and to heck with the other three"

The problem with this is business smokestacking. Where the infra, dev, and sec departments often have completely different managment stacks & there is often anamosity between some or all of the groups. Extracting DBAs into a seperate dept, potentially with their own independent managment stack only worsens this problem. This is elitism at it's worst (each dept is sure they're the best & should have final say in everything)

Why not take advantage of the existing departmentization and managment stack instead of fighting it? Each dept has it's own DBA & the DBAs work as a team. Within each dept, the DBAs are already within the managment structure and as such have authorization to make changes that impact that dept aspect of being a dba (ie, infra dba increasing db_recovery_file_dest_size when a developer needs to test something big). This stops the infighting and blame game because each dept has someone "on their side" in DBA decisions (no taxation without representation)

No, this is not how things are typically arranged & that is what is wrong. Isolate the DBAs from any one dept, and it will breed an us vs them mentatlity eithe amongst the DBAs or the isolated dept. Yet if the DBAs don't work with each other, this also causes issues.

There are examples of similiar xtra departmental groupings from other aspects of buisness. Take the following example from an insurance company. To sell the insurance policy requires a sales rep, an underwriter, records people, legal compliancy, and someone to bind the policy (I know, +/- some dept depending on different kinds of insurance. this is an example)
Business 1 : All depts are seperate. The policy slowly travels from the sales rep, through a randomly assinged underwriter, then on to a queue for a records check, back to uw for more work, on to legal compliancy, etc, etc, etc. Here there is no "ownership" of the process, each sub-process is owned by different depts, each with different priorties.

Business 2 : All depts are technically seperate, but teams are created consisting of members of each dept. Sales rep sends in information to a dedicated person in uw, who has a team member for all of the stages of the policy. Here the process is "owned" by the team. When there is a problem with one stage of binding the policy, there is a dedicated team member from the dept with an issue to quickly deal with it.

Which buisness will produce a quality product first?

In the same way a DBA team would "own" the database(s), yet each actually reports to individual depts depending on that DGA's unique task(s). When a new task arrises in dev that requires infrastructure change, the infra DBA has the authortity with the infra dept to get any changes done to accomodate. Example : dev creates new application and wants a new 4GB tablespace. The db host was running close on disk space, so this can't be immediatly accomplished by the infra DBA, but the infra DBA is in the infra dept. They go to the infra dept manager & make a case to get more disk space allocated for the db host. Since the need for more disk space came from WITHIN the infra dept, there is no inter dept infighting. Any justification the infra dept manager needs can come directly from the infra DBA. No managment gets in the way. It is a team effort for the DBA team and for in infra team.

The great things about this approach are that 1) it is free 2) it resolves ALL issues in a prompt way 3) it can be implement in ANY companies current managment topology

"because it leads you right back to what you say is the problem - animosity between the groups."

Have you ever witnessed a DBA distribution like I describe? Was there animosity between DBAs? You speak of hypotheticals based on your personal bias that a DBA is a developer and only a developer with a little bit if things outside of developing they may have to occasionally worry about. I speak of historical implementations that I have been a part of or know of. Not only does it work, it works BETTER than isolating the DBAs. Try it.

"There, they can work with any other group you dream up. They are all software implementers"

again, this is seperatism & breeds intra departmental conflict instead of fixing the issue. The larger the DBA group, the more important it becomes to diversify. Do you really want DBAs intimatly familiar with the inner workings of your company's primary production applications spending their precious time doing RMAN backups, dealing with disk space issues, doing account maint, etc. Do you really want the DBAs responsible for ensuring backups are valid spending their time tracking down a developers algorithmic flaw?

>> Have you ever witnessed a DBA distribution like I describe? Was there animosity between DBAs?

I don't know about Tom; but I have. I have been an Oracle DBA (and only that) since that Spring day in 1993, since version 6 where transaction processing was an extra-cost option; and I have been part of many types of organizations you have mentioned - a singular independent DBA group, part of Infra group, broken up into parts of the app team and all that. I have always been part of some DBA team; never a consultant. For the last 6 years I have been leading DBA teams (technical leadership; not pure management). The camaraderie and animosity - I have been through all that, and not always by choice.

Animosity has little, albeit something, to do with departmentalization. If you group a bunch of people with diverse skills together, will they behave like a happy family? Why should that alone makes them happy with each other, or hate one another? Being part of one department has nothing to do with it. On a grand scale, everyone is part of a larger organization - the IT department - anyway, isn't it so?

Animosity is rarely a result of groupings; it¿s almost always a result of failure to attend to basic human needs. If I disrespect someone, that person hates me, whether a member of the group or not. Similarly help begets appreciation and sense of camaraderie. Putting a bunch of people of homogenous skills in a single ¿department¿ does not necessarily create a band of thugs and breeds ¿us vs them¿ mentality. It may; but not just because of the grouping.

The term DBA is often misunderstood, or at least misinterpreted. In fact, you have shown some examples yourself. Perhaps that¿s what leads to the incorrect departmental positioning and subsequent lack of clarity in role. The concept of management division is usually based on consistency in roles and responsibilities and common specialization. Perhaps in really small companies where there are one or two DBAs, it may not make sense to create a separate department; but in larger companies, a common pool makes the management functions easier. Here are some practical reasons:

(1) People take vacations, get sick, go to Oracle Open World; or otherwise become unproductive. A group is better prepared to respond to such with built-in redundancy compared to one or two individuals in a diverse group.
(2) Success is rarely an accident; people execute and accomplish objectives. What motivates them is probably as diverse as shades of color; but one thing that definitely works is appreciation. A consistent group affords comparisons, fairness and subsequent appreciation, better than a diverse group of many individuals. I¿m not saying that always works; but it simply has a better probability or working.
(3) A group turns specialization into Standard Operating Procedures. How to take a backup is not something a group of very smart developers may come up with, at least not easily and definitely not on their own. DBAs taking care of databases ¿ a term people sometimes refer to as System DBAs ¿ can do that easily. They fed off each other¿s skills and may actually perfect SOPs so as to make the overall organization better. I have done it; so have many of my peers.
(4) Internal QA is a big plus. A group asking for resources from another group has to be cognizant of the limited nature of the latter. This often leads to efficiency. Example: as a DBA I feel it¿s frustrating to ask for space from storage folks. So, I economize on the storage ¿ less wasted space, which leads to better I/O and subsequently better performance.

Again, these are just some of the practical benefits; there are more, of course. The above arguments are hard to ignore, in any setting.

I will address a specific example you have given, simply because I face that scenario almost every month. Let me dissect it to basically four points:

(1) Dev wants more space
(2) There is no more space
(3) DBA makes a case for more space
(4) Infra group adds space

Dev DBA Storage
== asks ==> == asks ==>

Scenario 1: DBA is part of the infra group. Your assumption: since DBA is a part of the group that supports the storage, he can ask his departmental manager and voila ¿ the storage appears.

But, what about the origin of the request? The origin is the Development group; not the DBA. The DBA does not have to ¿make a case¿. If the management process is properly instituted, the request from Development, if legitimate, is automatically executed. If the management process is faulty, the friction starts right there ¿ such as: development asking for more space but there is no budget. Or, you are assuming development is part of the infra group as well? That would be a stretch.

The point is there is always a customer-provider relationship (which could heat up occasionally for the very nature of the transaction) in any business transaction. You assume putting the different entities into single group solves the friction. That is hardly the case. If the storage group has hit a physical limit on the SAN frame because of their mis-calculation and now needs to buy a whole new frame to add that measly 100 GB, management has to be involved. (It happened to me just 1 week ago).

Scenario 2: DBA is part of the development group. The DBA in this case, validates the need for space (the tablespace is really full) and makes the case to the storage folks, who are in the infra department. If the management process is well defined, this request simply becomes yet another normal task which is executed uneventfully. A flawed management process creates friction between infra group and the DBA. But how is that different from Scenario 1, where the friction is merely between Dev and DBA?

The true culprits in both the cases are systemic flaw in the organizational structure and maturity (or the lack of it) of the processes; it¿s never the placement of the DBA group. The ease of the interaction between the groups dictate the relationship ¿ the predictable the process, the smoother the relationship. Fuzzy, ill defined processes lead to frustration between suppliers and customers and lead to friction ¿ within a department or not.

As I mentioned earlier, my DBA team has been parts of many groups ¿ under DW manager, under Infra manager, under one specific app manager. It has been broken into small pieces and plugged under many app groups; and then re-grouped into a cohesive group later. We have been through all sorts of experiments. All I have learned from it is that there is no silver bullet. What works for me may prove disastrous for you.

Here is how it is structured now: one group of DBAs supporting 50+ diverse applications. Each application has a primary and a secondary DBA who have expertise in how the app works and interface to the infra group for all necessities ¿ space, CPU, kernel patch and so on. Some complex apps have more than one primary. The same group of DBAs also functions as the System DBAs with skills in RMAN, RAC, etc. Each technical skill has one or more specialists who are called in to solve issues in their domain. Finally, the same groups of DBAs also rotate as a Level 2 support on-call.

The advantage ¿ we have redundancy in cases of sickness and vacations. The DBAs are happy because they can keep up with Oracle technology skills while learning about a portion of the company business. They build servers, write scripts ¿ all things geeky DBAs do; and at the same time talk to developers and perform some development tasks as well. Does everyone do everything well? Of course not. Some people are pretty good in, say, SQL Tuning, as opposed to RMAN troubleshooting. Fine, they are specialists in that area and usually get work in that. We don¿t ask them to do only SQL Tuning every day; but allow them to dabble in RMAN and RAC as well, but primarily focusing on SQL Tuning.

Who do we report to? We report to the head of all Development Groups. Do we breed animosity? I don¿t think we have any more animosity outside the group as we have inside.

Will that work for you? May be; may be not. I am not advocating one model over the other; but merely pointing to the fact that there is no such thing called the perfect placement of the DBA group. So far, it seems to be working for us; and I hope it will continue to be so.

"Animosity is rarely a result of groupings" : Correct. It is the result of petty people. These people should change their attitude, but people are people & infighting happens.

"The term DBA is often misunderstood, or at least misinterpreted" : I absolutly agree. That is part of why I have specified different "kinds" of DBAs

Your reasons for creating a seperate DBA department are flawed. My argument would be that each DBA is a fully trained DBA, so
1) covering when other are out is easy
2) Your right, that's why they work together in an extra deparmental team
3) exceptions arrise to SoP all of the time. If the manual answered all, why even have a DBA after you've written your perfect procedures?
4) You make my point exactly. If the DBAs are external to any group from which they require resources, they are less likely to be cognizant of the actuall resources avaliablity and/or the impact such a request would have.

DBA deployment can be successfull as a seperate department.
DBA deployment can be successfull in a existing deparment such as development or infrastrucure.
DBA deployment can be successfull in a multi department role, in any size of company.

In business outside of IT, the value of extra deparmental teams has been recognized for DECADES. Why shouldn't IT take advantage of a system just because it didn't come from IT?

"I have learned from it is that there is no silver bullet. What works for me may prove disastrous for you." : YES!!! It comes down to the people. My argument that Tom would not acknowledge is that it CAN work in a way other than he is comfortable. In fact, it has been proven a more likely to succeed business configuration. But it will not always work & this comes down to people. Those set in their ways won't change.

Looks like this is becoming a long and emotionally discussed thread. Although much is said, I'd like to add my EUR 0.02 plus 19% VAT (yes, it's that much in Germany):

In my own humble experience (beginning on that summer day in 1997 when I joined Oracle), the most effective placement of a DBA in terms of "getting the job done well and quickly" is close to the developers, no matter which department/group you belong to.
But that also depends on the size of the organization, e.g. my current customer has about 3000 employees and a strict separation between development, test and production. So there are production DBAs and development DBAs with
- one dedicated Oracle expert in the production team
- other admins in the production team that look after DBs as well as application servers and other systems, being responsible for the whole operational part of an application
- several DBAs in different project teams caring for development and test systems.
- and one specialty, which is my team, described as "Oracle Development Support", belonging to a group that is an internal service provider to several different departments. Thus, this team doesn't solely think in "our group" terms but also "our customers".
- animosities - yet there are still some (Project: "we need a RAC", Ops: "nope, we stick to another architecture"), but often this is just a matter of people wanting to be involved. Communication is king concerning this issue.

So, in this model there are different types of DBAs in different departments. Some with a focus on operations, others with their focus on development. And, ideally, both communicating with each other. In my projects, this works out fine.

Fortunately I was able to convince my current customer to make my way to a cross-sectional placement. The consequences are that some folks in management have a mindset like "I don't really know what you are doing, but I don't mind as long as everything works smoothly". And I can live with that. ;-)

Best regards from Old Europe,
Uwe