July 3, 2011 at 4:29 pm
BWAA-HAAA!!! Ok, Craig... you started this. 😛 What are the answers to the two questions above?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2011 at 7:12 am
Jeff Moden (7/3/2011)
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]
The owner is the gal/guy which a$$ is on the line, the ultimate responsible - the one accountable for therefore, following this simple definition of ownership:
-- Developer owns the code - if code is wrong go after the developer,
-- Business owns the data - if data is wrong go after the business,
-- DBA owns the environment - if database has integrity problems or is not availlable, recoverable or doesn't perform whitin agreed SLA go after the DBA.
Just my two cents 😉
_____________________________________
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 4, 2011 at 7:40 am
I guess that's another 'it depend' answer.
In this case i depend on the size of the company.
If you have a small company with few devs, then they can own code or be responsible for something, but in bigger company with hundreds of devs that doesn't work anymore. Who owns the code? The dude who first wrote it? One of the 20 dudes who made modifications? The last dude who modified something? That guys who left?
Same thing goes for the DBA, if you only have a few servers and a few DBs the DBA can be owner of some code they reviewed, but as soon as you get more servers to manage that doesn't work anymore. DBA can't take decision of whether they can or cannot touch the DB, even if the server stability is in danger. Some DB might be less critical while other might need to keep running even if it's eating all the resources and starving the rest.
In big company you end up with application owner who can tell you what can or cannot be done on the DB.
July 4, 2011 at 8:17 am
BWAA-HAA!!! Actually, that's a pretty good definition! Well done.
However, I'd bet credits to Navy beans that if something goes wrong, the Business User will blame the Developers and the DBA's instead of the inaccurate or insufficient requirements they wrote. 😉 For that reason, I say Business Users own nothing because the frequently won't take ownership for problems they've been the cause of. In some very real sense, Developers (be they front end or DB) fall into the same category.
That's brings us to a diametricly opposite set of related questions. WHO should have ownership of what and WHAT are their responsibilities? We all know the answers to those questions... now we just need to teach them to the Business Users and the Developers. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2011 at 4:31 pm
Jeff Moden (7/3/2011)
BWAA-HAAA!!! Ok, Craig... you started this. 😛 What are the answers to the two questions above?
Heheh, busy weekend for me, sorry for disappearing.
What is ownership? It's a concept, an idea, in your head. It's who is responsible when it breaks, who is the one that raises their hand at a meeting and goes "That's mine, I'll take the bug and direct the fix."
Ownership is when you finally get to the nuts and bolts of the problem, who owns the job of 'fixing it'. They may not be the one who does the actual work, but its their butt who has to own the process. They have to do the research, or direct what research is to be done by others. They're the one who has to report to your local head honcho as to what, when, and why.
I'll agree, business owns data. Do they have to sign off on things to make sure audit channels are in place to make sure that A) I don't do crap without a CYA saying the owners wanted it? and B) So the rest of the owners aren't screwed by what one of the owners did? Sure. They own that.
We own the code, the nuts, bolts, and methods that makes their data work. Who's we? Good question. I'm purposely doing my best to stay in the 'neutral' position here, since I'm the pain in the butt who opened the doors.
Oliiii (7/4/2011)
I guess that's another 'it depend' answer.In this case i depend on the size of the company.
If you have a small company with few devs, then they can own code or be responsible for something, but in bigger company with hundreds of devs that doesn't work anymore. Who owns the code? The dude who first wrote it? One of the 20 dudes who made modifications? The last dude who modified something? That guys who left?
Same thing goes for the DBA, if you only have a few servers and a few DBs the DBA can be owner of some code they reviewed, but as soon as you get more servers to manage that doesn't work anymore. DBA can't take decision of whether they can or cannot touch the DB, even if the server stability is in danger. Some DB might be less critical while other might need to keep running even if it's eating all the resources and starving the rest.
In big company you end up with application owner who can tell you what can or cannot be done on the DB.
Oliii has stated the conundrum in a much more practical sense then I did, which had more to do with larger environmental lockdown methodologies and the difficulties that provides. I'd wondered if someone would bring up environmental size as the issue. Obviously, it can be. But do we usually create practices based on size, or on logical methodology?
The part in bold, however, is worth noting independently. How can you own something you inherited, and you have no idea why the hot air balloon is filled with lead lining? At the same time, if it's landed on your desk, how can you not?
DBA's will have a hard time owning logic. Devs will have a hard time owning implementation. The new guy? Well, he's just screwed.
Btw, Jeff, from my perspective this issue is more fundamental then just who slaps a signature on a piece of code. Can I get a DBA to review a one-off as a developmental owner because it breaks the generic security rules? Sure I can. Might be a fight for time but it'll get there with enough business pressure. The question comes down more to perception and who's rear is on fire for the choices made about ownership.
Allow me to present a scenario:
As a Dev, you've allowed them DBO access on 2 databases on an instance, and setup security so that ownership inheritance won't be an issue, but you're not allowing ownership chaining and this is a multi-database instance so you can't allow it because of possible security holes.
Your dev builds himself a nice little catchall dynamic search proc on DB1, uses information from a stored procedure on DB2, and it's built to standards. Runs a #tmp for intermediate results from DB2 since he's not currently able to directly access the foreign tables. Runs just fine in dev, scan/seek ratios in the plans seem fine, no logic glitches they can find.
QA, testing goes fine. It does what it needs as far as the business owners and their data retrieval is concerned.
It hits Prod, and BOMBS. Will not run in under 3 minutes, and occassionally just spins to death.
Who owns it? One of the five DBA's already working 50 hrs a week each on maintenance and has never seen this code other then an 'F5' to put the rollscript that went into QA into production (and might have done a few keyword searches for cursor, grant, execute as, and xp_cmdshell), or the guy who can't even login to the server, so he has no idea why that enviroment is having a problem with the code and logic he wrote?
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
July 4, 2011 at 4:55 pm
Craig Farrell (7/4/2011)
Who owns it? One of the five DBA's already working 50 hrs a week each on maintenance and has never seen this code other then an 'F5' to put the rollscript that went into QA into production (and might have done a few keyword searches for cursor, grant, execute as, and xp_cmdshell), or the guy who can't even login to the server, so he has no idea why that enviroment is having a problem with the code and logic he wrote?
Back at the bank that would have immediately become my problem. I was on the DBA team, sysadmin access in prod, but my responsibility was server performance, code reviews and development assistance (not actual development). Even if I'd never seen that code (though I likely would at code review time) it would have been my responsibility to investigate and identify and then explain to the developer why it crashed and burnt and what he should do instead.
Own the code? No, I never thought that. If the logic broke the dev worked with one of the admins to see what the cause was. It was just performance problems that came to me directly.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 4, 2011 at 10:26 pm
Craig Farrell (7/4/2011)
Who owns it? One of the five DBA's already working 50 hrs a week each on maintenance and has never seen this code other then an 'F5' to put the rollscript that went into QA into production (and might have done a few keyword searches for cursor, grant, execute as, and xp_cmdshell), or the guy who can't even login to the server, so he has no idea why that enviroment is having a problem with the code and logic he wrote?
[font="Arial Black"]THAT[/font] is exactly what I was talking about when I said there's a "shared ownership". People have to take ownership on both sides to resolve this. The only way to resolve such a problem is for one of the DBA's and the Developer need to sit should-to-shoulder and hammer out the problem.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2011 at 5:28 am
Oliiii (7/4/2011)
I guess that's another 'it depend' answer.In this case i depend on the size of the company.
If you have a small company with few devs, then they can own code or be responsible for something, but in bigger company with hundreds of devs that doesn't work anymore. Who owns the code? The dude who first wrote it? One of the 20 dudes who made modifications? The last dude who modified something? That guys who left?
Same thing goes for the DBA, if you only have a few servers and a few DBs the DBA can be owner of some code they reviewed, but as soon as you get more servers to manage that doesn't work anymore. DBA can't take decision of whether they can or cannot touch the DB, even if the server stability is in danger. Some DB might be less critical while other might need to keep running even if it's eating all the resources and starving the rest.
In big company you end up with application owner who can tell you what can or cannot be done on the DB.
Well... I beg to differ. I've worked for over ten years now for Fortune 50 (fifty) corporations and I can tell, the larger the company the more important ownership and change control are.
By the way, nothing is owned by an "individual" but by the team. Meaning no indivudual developer or DBA owns nothing, ownership falls on Deverlopers a.k.a. Apps Team and DBA Team. You can have subject matter experts but ownership is at team level where you can identify a single a$$ e.g. Apps Team Manager or DBA Team Manager - to be kicked when something is not right.
_____________________________________
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 5, 2011 at 5:48 am
That's what i meant by application owner, it doesn't have to be a single person but it's usually a team.
My example was already complicated enough, i didn't want to make it even more complicated 🙂
July 5, 2011 at 1:30 pm
The database developer really should be a SYSADMIN in the development environment, or at least have permission to VIEW SERVER STATE, ALTER TRACE, and SHOWPLAN permission. At the very least, give them SHOWPLAN permission. Otherwise, they are handicapped in terms of being able to debug or optimize their code. If the DBA thinks only he should be able to view database internals in every environment, then performance is totally his domain.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 5, 2011 at 1:36 pm
The database developer really should be a SYSADMIN in the development environment, or at least have permission to VIEW SERVER STATE, ALTER TRACE, and SHOWPLAN permission
Agreed - and in our case, it is immaterial of what goes wrong the first stop is the DBA.
Steve Jimmo
Sr DBA
“If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan
July 6, 2011 at 6:37 am
Okay, I guess I am a little puzzled.
The examples all seem to be around a developer producing code that's fine in development/test environments, but bombs in production. So we come to the question of who owns the code, the DBA (who is unfamiliar with the code) or the developer (who doesn't have the necessary access privileges to troubleshoot the code in production.)
Is there some reason why the DBA can't work with the developer to get it resolved? Or is cooperation a forbidden concept? Why does it matter who "owns" the code when the issue is how best to resolve a fault?
July 6, 2011 at 2:43 pm
Coming back in a little late to the discussion..
Jeff, business users won't take ownership unless you make them. In a former employer we made them take ownership by requiring them to sign off on function specifications, bascially the business rules they wrote interpreted by development. It made it a lot harder to weasel out, they couldn't go back to the business requirements and say "you didn't implement this per the business requirements", we could come back and say "we interpreted it this way and implemented it based in that interpretation AND you signed off on it BEFORE we started coding".
This allowed us to say we can change it but it will take more than just your say so.. It also made sure that we understood what was being asked of us. One of the things that the business was not permitted to do was say, "I want you to use this technology". Implementation tools and technology was determined by development and/or operations. Business units and departments were also not allowed to hire outside contractors if they didn't like our timelines or told them NO.
CEWII
July 6, 2011 at 4:41 pm
Elliott Whitlow (7/6/2011)
Coming back in a little late to the discussion..Jeff, business users won't take ownership unless you make them.
That's just not true, Elliott. Maybe not for you but I have Business users that are tickled to death to be involved. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2011 at 10:16 am
Jeff Moden (7/6/2011)
Elliott Whitlow (7/6/2011)
Coming back in a little late to the discussion..Jeff, business users won't take ownership unless you make them.
That's just not true, Elliott. Maybe not for you but I have Business users that are tickled to death to be involved. 😉
I think that highlights the variances in experiences. I was with a large organization that unfortuantely the business analysts were more than happy to throw development under the bus to prevent them from being blamed for a bad design or an implementation that wasn't popular. That isn't to say that development was blameless, but until we went to a more accountable process this happened more than I would like. Once we went to that model it helped the overall realtionship between both the users and the business. Our functional specifications showed how we intended to implement the business requirements and it gave the analyst a chance to verify that we did actually fulfill what was being asked of us and to go back to the users. The process also allowed development to challenge business requirements, given that many times a business requirement asked for the moon without realizing time and costs were much higher when in reality they just needed low earth orbit.. Basically, just because there is a requirement doesn't mean it will be implemented without discussion and compromise.
CEWII
CEWII
Viewing 15 posts - 31 through 45 (of 48 total)
You must be logged in to reply to this topic. Login to reply