InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 21:20:53 GMT20http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxI think Joel and Jeff are pointing out the difference between Responsible and responsible. My off-the-cuff answer to the original question was "Lower-case-r-responsible is good." As I think about it more I'd define stewardship roles and responsibilities as clearly as needed (depending on organizational needs) and have DBAs live on the side where they watch out for things but don't own them. Maybe data husbandry is a better notion than stewardship (since that word has been coopted by IT folks). Hmm, maybe not, since husbandry says more than just "judicious tending", it also implies decisions and control. OK, now I have a new metaphor to tinker with for the day...Tue, 06 Jul 2010 09:52:40 GMTCris Ehttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]joel.weiss 70857 (7/6/2010)[/b][hr]I agree with your mentor up to a point, and this is a critical point: a DBA, by definition, is an administrator, not an officer. Seeking out data and judging whether it is critical, real or worth saving is not part of the job. Overdoing this role contains an inherent risk of creating unnecessary infrastructure and producting redundant data, which is a different type of risk (accuracy). Leave those judgement calls to the CIO.[/quote]From the CIOs I've seen, this kind of concern is something they'd delegate at best. They have their minds on other things and in many cases either don't have the time for this kind of low-level activity or simply don't have the expertise needed.Tue, 06 Jul 2010 09:43:23 GMTStefan Krzywickihttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]joel.weiss 70857 (7/6/2010)[/b][hr]I agree with your mentor up to a point, and this is a critical point: a DBA, by definition, is an administrator, not an officer. Seeking out data and judging whether it is critical, real or worth saving is not part of the job. Overdoing this role contains an inherent risk of creating unnecessary infrastructure and producting redundant data, which is a different type of risk (accuracy). Leave those judgement calls to the CIO.[/quote]Not that every company will have this kind of sensitivity but if I had done that in the past, the company would have been out of business for being sued because the CIO was also a DA (and that's not a legal term in this case). ;-) Sometimes you have to protect the officers from themselves. :hehe:Tue, 06 Jul 2010 06:23:57 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]paul s-306273 (7/5/2010)[/b][hr]Off topic, but when did SSC-Insane ranking come in?[/quote]It seems like Steve made it up right after I tipped the 20K mark. Since I'm the only one that fits the category (so far) and he carefully excluded himself, it seems he may be trying to tell me something. :-PTue, 06 Jul 2010 06:19:38 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxI agree with your mentor up to a point, and this is a critical point: a DBA, by definition, is an administrator, not an officer. Seeking out data and judging whether it is critical, real or worth saving is not part of the job. Overdoing this role contains an inherent risk of creating unnecessary infrastructure and producting redundant data, which is a different type of risk (accuracy). Leave those judgement calls to the CIO.Tue, 06 Jul 2010 06:15:17 GMTjoel.weiss 70857http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxOff topic, but when did SSC-Insane ranking come in?Mon, 05 Jul 2010 14:26:47 GMTpaul s-306273http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxYour organization is lucky to have someone like him. But moving the data is the easy part... you'll have to coordinate with app dev to get their gui converted over to use the new datasource. Which is much more political and difficult to do. Usually cannot happen unless the guy/gal has some pull in the company.Mon, 05 Jul 2010 12:15:01 GMTsyi916http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxI think a DBA reacting to situations like this they encounter is fine. If you learn of critical data being stored in an unsafe way, by all means speak your mind.But these days with so much information to be kept, and the ubiquity of excel and access, I think this needs to be managed more proactively and I'm not sure that the DBA should be the person to do that.I think when it comes to going out and finding this type of thing, that is both just easier and a more natural role for an IT manager/CIO to be doing.Mon, 05 Jul 2010 10:13:20 GMTNevynhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]paul s-306273 (7/5/2010)[/b][hr]It's commendable for anybody to be pro active, but I don't think it is the DBA's responsibility. I thought that was why organisations employed Data Managers and CIOs.[/quote]It obviously depends on the size and structure of the organization. But knowing human nature, if something goes seriously wrong, isn't it a bit naive not to assume that the the person whose head will roll is the DBA, because (a) they is the person at the operational coalface and hence best placed to protect the data (whether they were explicitly given responsibility for a given DB or not); and (b) because they will be lower in the pecking order than the CIO or data manager?I think Brad is correct. Looking for critical data to protect is good practice. You could call it due diligence.Mark DalleyMon, 05 Jul 2010 07:15:20 GMTMark Dalleyhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxIt's commendable for anybody to be pro active, but I don't think it is the DBA's responsibility. I thought that was why organisations employed Data Managers and CIOs.Mon, 05 Jul 2010 04:13:28 GMTpaul s-306273http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxYou have to trust your administrators. You can contract with them, bond them, have them liable for things, but ultimately you must trust themSun, 04 Jul 2010 17:15:17 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]GPO (7/3/2010)[/b][hr]So (sorry for sounding dumb) how do you handle situations where the data has a significant level of sensitivity and you want the DBA to manage it, but not read it, and certainly never change it? Is this where encrypting columns etc comes into it? Would it be fair to say that this falls into the "Too Hard" basket a lot of the time, and the CEO, through ignorance of the technology, basically ends up placing more faith in the DBA's goodwill than is necessary or desirable? How many CEOs would really know what their DBAs have access to?[/quote]It's an interesting question, but it's ultimately a "damned if you do and damned if you don't" kind of scenario. If you were to devise a scenario allowing you to store data so that NOONE else can get to it, then you and you alone would be responsible for that data, which would put the company at a severe disadvantage if you to leave/be fired/step in front of the proverbial bus etc.... All of those aspects surrounding safeguarding the data (access/encryption/backups, auditing) would then need to fall on the end-user rather than any centralized role.Someone ultimately needs to be able to retrieve your info in any of those scenarios or have access to the keys that unlock the access to said data (encryption keys, etc....), so someone has to be trusted with it. While at that point it might be desirable to break that up among several people, once you're at that point, it's really more a matter of knowing WHO has the access. It's funny - in many industries having someone in that role would actually be required, since pretty much anyone falling under Sarbanes/Oxley would need to functionally be able to retrieve sensitive data to turn over for review.I'd say it's actually a little safer to presume that anyone in those few positions (DBA, domain admins, storage admins, etc...) will by nature have access to sensitive data, and should be trained and hired with these concerns in mind. This then kind of ties back into Brad's initial question: DBA's (and others) then become guardians of the data for the corporation.Sun, 04 Jul 2010 16:39:48 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxGreat article Brad.Sun, 04 Jul 2010 15:31:47 GMTCameronMergelhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxSo (sorry for sounding dumb) how do you handle situations where the data has a significant level of sensitivity and you want the DBA to manage it, but not read it, and certainly never change it? Is this where encrypting columns etc comes into it? Would it be fair to say that this falls into the "Too Hard" basket a lot of the time, and the CEO, through ignorance of the technology, basically ends up placing more faith in the DBA's goodwill than is necessary or desirable? How many CEOs would really know what their DBAs have access to?Sat, 03 Jul 2010 13:57:16 GMTGPOhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspx[quote][b]Sean Josiah-454849 (7/3/2010)[/b][hr]Jeff:thus systems have to have 100% uptime, people can't get sick or go on vacation, and nothing fills the round file. yet the world keeps spinning, and todays frenzy is forgotten by next week.[/quote]I can't tell... are you bragging or complaining? ;-)Sat, 03 Jul 2010 13:46:07 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxJeff:thus systems have to have 100% uptime, people can't get sick or go on vacation, and nothing fills the round file. yet the world keeps spinning, and todays frenzy is forgotten by next week.Sat, 03 Jul 2010 12:27:39 GMTSean Josiah-454849http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxHeh... I do find it amazing that certain types of data are considered to be NOT mission critical... that is, until it's lost. ;-)Sat, 03 Jul 2010 11:57:36 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxI can understand the impetus and I agree that it is a process that should be applied, however with moderation. Not all data in the organization should be classified as mission critical. Some of these less structured efforts and data stores are outgrowths of staff and departments finding ways of architecting better, simpler supporting processes. This is actually an indicator that the established systems do not meet all the needs, access to the database platform is not distributed, and additional training is needed at the department levels.The DBA would need to share db space, architecture and time to train many other non-DBA's. Locking down, improving data quality, ensuring data accessibility and securing are worthwhile goals but not at the expense of stifling and slowing responsiveness. Bottlenecks will be formed one way or the other and we should be mindful of the kind of bottleneck we are, sponsoring, etc. All applications and reports that are relied upon daily by key stakeholders should be targeted for 'protection'. Those applications and reports that are used by more than two departments are clearly important and should be included in the 'protection' net. Additionally any non daily applications that are relied upon by a large number of users should also be targeted for 'protection'. Most of the Homegrown applications require time to mature and can be ignored until they too are used by either key stakeholders or large number of users.'Protection' in my view should be measured, used as an indicator for more training, inclusion of other parties but not as a means of controlling development of prototypes and 'glue' integration solutions. Instead use the discovery of these innovations as the opportunity to ask why it was needed and how can that be addressed?Sat, 03 Jul 2010 11:47:08 GMTSean Josiah-454849http://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxYou absolutely have to protect the data, which means many things.However I'm not sure you need to move it all into SQL Server databases. What you should do is help the person who uses it determine how to protect it and ensure it is useable. That might be making sure copies are on network shares through an automated process, or a copy to a db using OPENROWSET. As you protect data, you can't also make it unavailable or interrupt business processes.Sat, 03 Jul 2010 11:33:39 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxI agree with your mentor. So far as I'm concerned, a DBA's only job is to protect the data. Anything and everything else a DBA does is in support of that single job.Sat, 03 Jul 2010 11:22:09 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic947221-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/70653/">Should DBAs Be the Protectors of Data?</A>[/B]Sat, 03 Jul 2010 10:56:45 GMTbradmcgehee@hotmail.com