March 19, 2018 at 8:44 pm
Comments posted to this topic are about the item Are You a Traffic Cop?
March 20, 2018 at 2:31 am
Who decides where is the line drawn?
My experience has been that a decision needs to be made concerning the security of data or a continuity of service issue. Its not clear who should make that decision and certainly no-one is stepping up to the plate. That leaves the DBA in the position of being damned if they do, damned if they don't.
It's a double edged sword. If you say NO too many times you'll get an outbreak of NOSQL, but on the plus side those who have to manage the NOSQL solution discover all the pain points of data management from first principles treading in every turd and bear trap along the way. I caught one saying NO then patiently explaining.......
March 20, 2018 at 4:14 am
As a dba you always have to remember that you are the steward of the databases, have a supporting role, and that you should use your skills to the benefit and success of all people in the organization you work for.
So: Use your skills to keep the databases happy and healthy knowing that there will be the constant pressure of changing requirements.
This includes but is not limited to:
- Supporting the development teams, helping them succeed, educating them, showing them for instance how you tune queries, what to look for, etc.
- Maintaining sufficient performance headroom in your hardware, so that if something is going wrong it doesn't immediately escalate into heavy service impact.
- Monitor, monitor, monitor. Make sure you have 360 degrees visibility, so that if something changes that has impact, you can identify it rapidly and help fix the problem.
'Traffic cop' dba's have no place in the current rapidly changing business environment.
March 20, 2018 at 4:25 am
I'm more of a crossing guard as opposed to a traffic cop.
Traffic cops at least have some authority. Crossing guards just kind of pull and push little kids to a new destination. If the kiddies go to the wrong way, there's not much they can do. But if the kiddies get in trouble, the crossing guards are the first ones to get the heat!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
March 20, 2018 at 5:18 am
'There's a joke that a DBA's favorite word is "no". '
Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) Teacher
Things can go much smoother when #s 4 and 5 can get the higher priorities.
Mike Hinds Lead Database Administrator1st Source BankMCP, MCTS
March 20, 2018 at 6:16 am
Mike Hinds - Tuesday, March 20, 2018 5:18 AM'There's a joke that a DBA's favorite word is "no". 'Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) TeacherThings can go much smoother when #s 4 and 5 can get the higher priorities.
That's a joke? I worked with two DBAs, one a SQL Server DBA and the other, a DB2 DBA, whose standard answer was always "No".
That's funny! "Don't Bother Asking". I like that.
March 20, 2018 at 7:24 am
This discussion is perennial and disheartening. DBA expertise is indispensable for successful development. Databases are worthless unless they are being served to clients. Contention between the two is the opposite of good business. My advice to DBAs is to make your systems flexible to enhancement. My advice to developers is to release new functionality constantly, but otherwise do as you are told.
March 20, 2018 at 7:24 am
I think that the stereotype is based on some reality (aren't most stereotypes). In my opinion this is the result of someone getting too much power with too little knowledge and understanding. Sure a DBA is responsible for the safety and integrity of the data. But what happens in these cases is that the DBA seems to forget that the data belongs to the company, not the DBA. Part of the DBA role is security and integrity but that is pointless if the accessibility is forgotten or ignored. Anybody can say NO, it takes a real person to say "yes we can do that once I figure out how I can give you access and maintain data security". Most of the time the decision about who can access and maintain data should be up to the business, not the DBA. Just my 2¢.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 20, 2018 at 7:59 am
I think it depends on the culture you're in. When I worked at a Bank and Hospital, you valued stability over change. Now that I work in a development shop, the value is placed on rolling out new features in order to generate, or support, revenue. The caveat here is, they want the DBs to be available and fast at all times. I think the trick is to be open to change, but maybe in smaller chunks that can be easier to roll back. Focus on stability with changes. Air traffic controller vs traffic cop.
March 20, 2018 at 8:20 am
Does anyone track and report on the causes of data breaches? How much of the risk if from social engineering, how much is from failing to keep up and how much is from a combination of these two?
412-977-3526 call/text
March 20, 2018 at 8:21 am
Sean Lange - Tuesday, March 20, 2018 7:24 AMMost of the time the decision about who can access and maintain data should be up to the business, not the DBA.
If they accept that responsibility then that is fantastic. My experience is that they are very backwards and coming forward to take that responsibility.
Clearly data only has value if it is used. A write-only data store is of no use to anyone other than a storage salesman.
March 20, 2018 at 8:34 am
David.Poole - Tuesday, March 20, 2018 8:20 AMSean Lange - Tuesday, March 20, 2018 7:24 AMMost of the time the decision about who can access and maintain data should be up to the business, not the DBA.If they accept that responsibility then that is fantastic. My experience is that they are very backwards and coming forward to take that responsibility.
Clearly data only has value if it is used. A write-only data store is of no use to anyone other than a storage salesman.
Actually most people in business are quite happy to make that decision. The trick is in providing them tools so they can (and need to) manage application access themselves. Sure that sometimes means that people may have access to stuff they shouldn't but since business is who controls that access (also just data) it is their responsibility. Most people these days really expect application to give them lots of power. And with that power comes lots of responsibility. No longer do we have people sitting around a computer doing nothing but managing access to various applications for people in the company. Instead we put the functionality in the hands of the users to control access. That gives them the freedom they want and allows IT folks to work on actual IT stuff instead of managing data. Our company was (and still is in a lot of way) a pretty challenged environment when it comes to technology and forward thinking. But in recent years we have been providing more and more ability for users to control their own data and it is paying off. Often when we get requests from business these days it will include the line, "and a way to manage the data ourselves". They have begun the transformation into doing things like managing their own lookup tables and that sort of thing in addition. I have often said that it is the job of IT to build them software flexible enough that I work myself out of a job. The reality is that will never happen because there are always new demands. But it does mean the software that is complete is no longer an IT issue. We give the power to the users and IT doesn't need to be on call 24-7 and we can actually do this crazy thing around here where business and IT actually work together to design systems. They get involved with the process and everyone wins. They get the software they actually want and we only have to write twice which is a vast improvement over the standard 3-4 times. 🙂
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 20, 2018 at 8:39 am
Michael L John - Tuesday, March 20, 2018 4:25 AMI'm more of a crossing guard as opposed to a traffic cop.
Traffic cops at least have some authority. Crossing guards just kind of pull and push little kids to a new destination. If the kiddies go to the wrong way, there's not much they can do. But if the kiddies get in trouble, the crossing guards are the first ones to get the heat!
That's funny.
March 20, 2018 at 8:50 am
David.Poole - Tuesday, March 20, 2018 2:31 AMWho decides where is the line drawn?
My experience has been that a decision needs to be made concerning the security of data or a continuity of service issue. Its not clear who should make that decision and certainly no-one is stepping up to the plate. That leaves the DBA in the position of being damned if they do, damned if they don't.It's a double edged sword. If you say NO too many times you'll get an outbreak of NOSQL, but on the plus side those who have to manage the NOSQL solution discover all the pain points of data management from first principles treading in every turd and bear trap along the way. I caught one saying NO then patiently explaining.......
No idea. This is a tough line, and I'd say this should be collaborative. If the DBA is just trying to avoid work or prevent change to make their life easier that's where we start to have issues. We need to move forward, and there should be valid, stated, logical reasons for limiting or preventing work. Ultimately, if there is a question of performance, than management can make the call, but they should do so in writing so the DBA isn't being blamed for poor application/db performance.
March 20, 2018 at 9:07 am
Sean Lange - Tuesday, March 20, 2018 7:24 AMI think that the stereotype is based on some reality (aren't most stereotypes). In my opinion this is the result of someone getting too much power with too little knowledge and understanding. Sure a DBA is responsible for the safety and integrity of the data. But what happens in these cases is that the DBA seems to forget that the data belongs to the company, not the DBA. Part of the DBA role is security and integrity but that is pointless if the accessibility is forgotten or ignored. Anybody can say NO, it takes a real person to say "yes we can do that once I figure out how I can give you access and maintain data security". Most of the time the decision about who can access and maintain data should be up to the business, not the DBA. Just my 2¢.
This isn't really about deciding who has access, but rather, do we pettily enforce the letter of the rules laid out or do we ensure that work still gets done and we try to facilitate access. Not be silly, like granting SA to people, but trying to be careful and cautious where appropriate, but not impeding efforts.
Viewing 15 posts - 1 through 15 (of 40 total)
You must be logged in to reply to this topic. Login to reply