June 28, 2011 at 12:17 am
Hey Jeff. 🙂
I'd hoped you'd swing by. I really didn't want to utterly derail the other thread and something like this can take on a life of its own.
You'll pardon the trimming to the particular points I'd like to address, I hope. Don't worry, I'm not trying to take you out of context.
Jeff Moden (6/27/2011)
The Developers own the code 100% right up to the point where they turn it over to the DBA for promotion to production. [The DBA] has (or should have) the right to turn back any code that doesn't meet company standards and certainly any code which is classified as "dangerous".
The same goes for data. Once it enters the realm of production, the DBA owns the data and must guard it.
That's the long story. The short story is (IMHO), that once something is turned over to the DBA, the DBA owns it lock, stock, and barrel.
The previous owners (Developers) are responsible for that and that's likely a hint to the real key to all of this. 😉 It's a shared ownership.
To sleep — perchance to dream: ay, there’s the rub!
Here's where that concept gets caught. Yes, YOU as a DBA may own your server's code. I know many, including myself depending on the environment, who don't. They own and protect the servers. They protect the databases from each other. But what happens inside is, as far as they're concerned, a black box unless it's chewing on resources inappropriately. They set up security rules to make sure nothing gets deployed they'd need to care about, each db set having its own logins to disallow accidental crossover. Serverwide settings to shut down things that might 'escape'.
It's a workload issue. As IT centers cut costs more and more, administrators are barely able to simply keep up with just administration workload and really can't even attempt a code review. So you lock the server up tight, let the database have fun internally, lock out everyone but the app to cover your butt from SOX because any code roll had to go through QA, and get back to restoring another database for yet another developer on server Random0008, or back to trying to puzzle out why Lightspeed told the tape machine that rewind instead of copy was a good idea. Forget trying to review code, you're trying to kick this out the door because you're prepping for the OTHER rollout also happening on that Saturday because the only rollout time you get is when noone's on the floor.
Is it a manpower and preparation issue? Yes. But it's becoming more prevalent for DBAs to only own the servers and production level issues, and that's it. As you can see by some of the responses above, it's not an uncommon view. DBAs don't get to reject code in many shops, it's just simply their job to make sure it can't take down anything else. QA and UAT rejects code, the DBA is the monkey who rolls it, and the guardian against accidental crossover mishaps, or bad design being allowed to escape its confines.
Do I agree? Heck, I don't know. In my first real shop I owned all the servers and cowboy'd production like it was my personal tinkertoy. I know how well that turned out for me a few times. However, you're the first one to say it's NOT just the Devs, so I figured I'd point out all the challenges I see to your opinion. Hopefully you might have some solutions. Particularly ones that work with the mindset of business these days in regards to administrators... hiring more is rarely an option. That's what QA is for, and they're cheaper.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 28, 2011 at 12:49 am
Here is my take on this.
In here we have 3k+ SQL DBs over 110 servers, we are 5 DBA to handle SQL and Sybase.
Usually 3-4 DBAs are busy trying to find out why Sybase just did what it did, so that leaves around 2 DBAs to handle all SQL server related things.
Neither the Dev nor the DBA owns things, each DB belong to an application, each application has an owner (which is conveniently called an application owner).
Anything done on a DB in QA and PRD need to have the application owner's blessing. He's the only one who knows the impact of the change.
Devs change all the time so they can't own anything and DBA don't have to know what's going on in the DB as long as it behave within the SLA.
The Dev have all the access they want in Dev, reduced rights in TST and nothing above.
The DBA execute the deployment scripts or package (which cannot change after TST).
If something goes wrong it's the application owner's responsibility.
Do we have time to review the code? Of course not, we would need 50 DBA to do it.
We only spend time reviewing code when there is something seriously wrong or when an application owner opens a project and give us some man hours to do it.
Is that bad? Not really, having some code misbehaving from time to time is way less expensive than 50 full time DBA. And with our experience we develop a sixth sense to detect bad scripts.
The secret of all this going smoothly is having just the right amount of paperwork to do, enough to make sure the right folks are aware of what's going to happen and to deter some folks from wasting our time and not too much to become cumbersome.
June 28, 2011 at 12:55 am
I think the answer is quite clear for me , the guy who writes the code owns it esp since if there is a issue in production the dba will only assist in making sure the server remains functional. The code still goes back to the developer with input from the DBA about what issues it was causing .
For example , If i write a query that causes a locking or blocking issue. I would expect the DBA to identify that the system is being impacted by it , but i would not expect him to fix the code.
However Before the code is promoted the developer is responsible to make sure he has followed some guidelines as to performance etc as he know the DBA has to support the code in the server for the next few years.
Now as a DBA I would still run thru the code for checks on things like granting sysadmin privileges , dropping objects etc , esp since if the deployment does not go thru I would be expected to rollback and as a result i need to know the kind of objects being rolled back and what impact they have on existing functionality.
June 28, 2011 at 1:18 am
I like to compare DBA's to car mechanics. A car mechanic is responsible for the maintenance, performance and running of a car. He can spot design faults and implement workarounds and fixes. He can also relay those to the car designer who can apply those changes to future models of the car.
In this example, the developer is clearly the ultimate owner of the design and responsible for the performance of their code. But at the end of the day, the DBA is responsible for the running of their SQL estate and if a modification is required on the fly to keep the system running it needs to be done. A DBA cannot "pass the buck" and say its not my code so its not my fault the system isnt running as it should.
June 28, 2011 at 9:01 am
george sibbald (6/27/2011)
toddasd (6/27/2011)
george sibbald (6/27/2011)
...I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.
I feel like the odd-man-out in that I apply release code to production and not the DBAs. Seriously, I fill out the change management forms which get approved by management and business but never DBAs. Once the CM is approved, I have a time slot with free-range in production to apply changes (and, as it turns out, to reverse those changes). I don't see why the DBA would do that anyway. They have all the servers and databases to manage and have no idea what business logic is going into the code.
Its a question of access normally, and we are talking about SQL development, not front end stuff. So, code that goes on the SQL server. ...
That is what I'm talking about.
______________________________________________________________________________
How I want a drink, alcoholic of course, after the heavy lectures involving quantum mechanics.
June 28, 2011 at 7:52 pm
Craig Farrell (6/28/2011)
Here's where that concept gets caught. Yes, YOU as a DBA may own your server's code. I know many, including myself depending on the environment, who don't.
So... despite what anyone says on this thread, it all boils back to the same thing. The answer to the question in your original post is... "It Depends". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 28, 2011 at 9:38 pm
I have to agree with Jeff in many respects. I would chose to use a different term, however, when it comes to the DBA and ownership of the production systems. I'd prefer the term steward. We don't own the data or the code but are stewards of it, responsibile for protecting both the data and code from inappropriate changes or loss.
DBAs are more likely to be the ones called on to perform performance tuning of databases/code, even if the changes have to go through developers and development and test. One reason for this is access to the production servers. They are in a position to setup and run server-side traces to help diagnosis poor performing code, and they will tend to be the oneswho actually understand the system and how it works. They may not know the business rules and requirements, but that shouldn't stop them from understanding how the system works.
This is why DBAs and Developers should learn to work together rather than against one another.
If these two groups can work together, then the code ultimately developed and put into production has a better chance of doing what is expected and do it correctly. Not saying it always will, but the different perspectives looking at the code may catch things that may other wise slip through to production.
June 28, 2011 at 11:04 pm
Jeff Moden (6/28/2011)
Craig Farrell (6/28/2011)
Here's where that concept gets caught. Yes, YOU as a DBA may own your server's code. I know many, including myself depending on the environment, who don't.So... despite what anyone says on this thread, it all boils back to the same thing. The answer to the question in your original post is... "It Depends". 😉
I'm going to find a way to shoot that escape hatch one of these days... right after I get done using it so often myself. 😛
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 29, 2011 at 9:51 am
Craig Farrell (6/27/2011)
The DBA: ... Has little knowledge of what any particular database actually does other than pushing data out to something that requests it, and almost no intimate knowledge of its workings.The Dev: ... This is the guy who can't see prod but knows what the code is doing, but doesn't usually have access past DBO on his own databases in dev. ... Wait_Types and sp_lock are forbidden to him, don't even mention running a trace.
Hmmm... I'd have to wonder who the third person who sets up security is? The DBA can't set fine grained security if the DBA doesn't know about the data in the databases, and the Dev can't set security without having permission to do so. These two roles seem to be arbitrarily limited; in particular, it's not really practical for the developer to provide truly efficient solutions without a development environment that allows profiler/trace/network/SAN type tools.
Also, they must share ownership, for the code is worthless without the data. If the code's acting funny because prod has different data (garbage, perhaps) than the Developer can see, then neither one can solve the issue by themselves; therefore, neither one can truly "own" the issue.
Code ownership isn't as relevant as owning the means to fulfill business requirements, which is often by a nebulous group of people.
Responsibility without authority is silly, if common. Neither has full authority for what happens in production under the conditions stated above; therefore, neither can have full responsibility by themselves.
June 29, 2011 at 10:07 am
Developer owns the code.
Business owns the data.
DBA owns the database environment and is responsible for: Integrity, Availabiltiy, Recoverability and Performance.
_____________________________________
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.July 2, 2011 at 11:17 am
PaulB-TheOneAndOnly (6/29/2011)
Developer owns the code.Business owns the data.
DBA owns the database environment and is responsible for: Integrity, Availabiltiy, Recoverability and Performance.
Perhaps in your environment.
In our environment, all phases of a system enjoy a shared ownership. A couple of examples are in order:
A Developer in our environment owns the code right up the mandatory peer review in which the peer-reviewer has as much ownership as the original Developer. Changes to the code may be made by both parties. The code cannot and will not move to the next phase unless both agree. Once the code is checked-in, they no longer have ownership of the code. Rather, ownership is transferred to QA and the Developers may not modify the code in any fashion without the explicit permission of the new owner.
Another example... although it is perceived that "Business owns the data", Business may not make any changes to the data nor insert new data nor delete existing data except by approved methods. A DBA shares the ownership of the data. If you don't think so, consider that a DBA is bound by law and ethics (especially in SOX compliant environments) to ensure that even Business users cannot make illegal changes to the data. The DBA is the ultimate owner and protector of the data and that also includes times when the data isn't actually in the database, yet.
An example of the above is found in the ages-old interview question... The DBA is working late and the CFO of the company comes up to him/her with a list of data that needs to be changed immediately. What should the DBA do? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2011 at 11:47 am
Jeff Moden (7/2/2011)
PaulB-TheOneAndOnly (6/29/2011)
Developer owns the code.Business owns the data.
DBA owns the database environment and is responsible for: Integrity, Availabiltiy, Recoverability and Performance.
Perhaps in your environment.
In our environment, all phases of a system enjoy a shared ownership. A couple of examples are in order:
A Developer in our environment owns the code right up the mandatory peer review in which the peer-reviewer has as much ownership as the original Developer. Changes to the code may be made by both parties. The code cannot and will not move to the next phase unless both agree. Once the code is checked-in, they no longer have ownership of the code. Rather, ownership is transferred to QA and the Developers may not modify the code in any fashion without the explicit permission of the new owner.
Another example... although it is perceived that "Business owns the data", Business may not make any changes to the data nor insert new data nor delete existing data except by approved methods. A DBA shares the ownership of the data. If you don't think so, consider that a DBA is bound by law and ethics (especially in SOX compliant environments) to ensure that even Business users cannot make illegal changes to the data. The DBA is the ultimate owner and protector of the data and that also includes times when the data isn't actually in the database, yet.
An example of the above is found in the ages-old interview question... The DBA is working late and the CFO of the company comes up to him/her with a list of data that needs to be changed immediately. What should the DBA do? 😉
I respectfully disagree. I stand by my position which is the only one that allows for responsibilities assignment and accountability.
DBA changing data? :w00t: man, you are in serious troubles.
The only way DBA may change data is by executing a Developer's provided query that was approved by both QA and the Business. All steps documented on a proper Change Control system.
That's best practices, that's the right way to do it.
_____________________________________
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.July 2, 2011 at 1:46 pm
PaulB-TheOneAndOnly (7/2/2011)
I respectfully disagree. I stand by my position which is the only one that allows for responsibilities assignment and accountability.
I wrote a rather long post... what is it that you disagree with. And it's ok for you to stand by your position for you... it's just not right for everyone.
If what you're taking exception to is the DBA changing data, congratulations... your answer is correct... the DBA should not change the data even if one of the supposed "owners" tells the DBA to change it. That's my whole point... if the business owner actually owned the data, the DBA would have no choice but to change it. 😉 In this case (which is the correct way), the "business member" not only doesn't own the data, (s)he doesn't even have direct access to the data.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 3, 2011 at 10:23 am
Jeff Moden (7/2/2011)
PaulB-TheOneAndOnly (7/2/2011)
I respectfully disagree. I stand by my position which is the only one that allows for responsibilities assignment and accountability.I wrote a rather long post... what is it that you disagree with. And it's ok for you to stand by your position for you... it's just not right for everyone.
If what you're taking exception to is the DBA changing data, congratulations... your answer is correct... the DBA should not change the data even if one of the supposed "owners" tells the DBA to change it. That's my whole point... if the business owner actually owned the data, the DBA would have no choice but to change it. 😉 In this case (which is the correct way), the "business member" not only doesn't own the data, (s)he doesn't even have direct access to the data.
I think we are on the same page - just saying things in a different way.
Onwership of the data does not equates with ability to manipulate the data; morevoer, DBA do not get marching orders from Business. Data is either manipulated by the application or by developer provided special a.k.a. "fix" scripts properly approved by both Business and QA.
_____________________________________
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.July 3, 2011 at 4:27 pm
PaulB-TheOneAndOnly (7/3/2011)
I think we are on the same page - just saying things in a different way.Onwership of the data does not equates with ability to manipulate the data; morevoer, DBA do not get marching orders from Business. Data is either manipulated by the application or by developer provided special a.k.a. "fix" scripts properly approved by both Business and QA.
'Zactly! And that's the true "rub" to this thread and others like it... [font="Arial Black"]What is "Ownership" here? What does "Ownership" actually mean?[/font]
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 16 through 30 (of 48 total)
You must be logged in to reply to this topic. Login to reply