RE: New Survey
- From: "Blanchard, William" <wblanchard@xxxxxxxxxxxxxxxxxxxx>
- To: "Freeman, Donald" <dofreeman@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 16 Dec 2009 14:21:28 -0600
Great idea - printing out emails. They may not believe me because
they're Project Managers high above the fray looking down on their
fiefdom but if I play pile on with emails and the survey they should,
hopefully, get on board with the rest of the world.
WGB
-----Original Message-----
From: Freeman, Donald [mailto:dofreeman@xxxxxxxxxxx]
Sent: Wednesday, December 16, 2009 1:45 PM
To: Blanchard, William; oracle-l@xxxxxxxxxxxxx
Subject: RE: New Survey
My office supports 128 programs with lots of databases both Oracle and
SQL. Unfortunately our approach to developers, business owners, and
consultants across the enterprise is inconsistent. In our worst case we
have a business owner who years ago bought his own (mission critical)
application and support from a contractor. He wanted the whole thing,
servers and all, set up in his office without any departmental IT
support at all. In retrospect we should have let him. His team has
full access to the production database and have developed any number of
business processes that require manual intervention by his office staff.
My DBA predecessor revoked all those privileges one time and then was
forced to re-grant them because it put the office out of business. It's
a case of his daddy is bigger than my daddy.
In the second tier of "bad" are applications (a couple) that have
imbedded passwords that are known to development staff or contractors.
In one of these the application user is the application schema owner.
These are the kind of things that I have named, perhaps not originally,
zero-day architectural decisions that last the life of the application.
Lastly are those, the majority, where developers, and some super-users
have read-only access to the databases. Now, when we on-board a new
application I'm there to ask these questions up front. I have to say
that our application development team management is a lot better than it
used to be also. They've got some more effective checklists.
As well as your survey you might print out some of these emails.
Donald Freeman
Database Administrator II
Commonwealth of Pennsylvania
Department of Health
Bureau of Information Technology
2150 Herr Street
Harrisburg, PA 17103
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Blanchard, William
Sent: Wednesday, December 16, 2009 2:04 PM
To: Goulet, Richard; oracle-l@xxxxxxxxxxxxx
Subject: RE: New Survey
I would be happy just being able to lock them out of production
(read-only access). I'm trying to run uphill into a 100mph headwind.
WGB
-----Original Message-----
From: Goulet, Richard [mailto:Richard.Goulet@xxxxxxxxxxx]
Sent: Wednesday, December 16, 2009 12:49 PM
To: Blanchard, William; oracle-l@xxxxxxxxxxxxx
Subject: RE: New Survey
William,
I have no problem with developers having READ ONLY access to
production, staging, and QA. It gives them an ability to research
problems with the app without always having to bother me. Beyond that no
I do not approve of developers having access to anything other than DEV
& I like to throw them all out on a monthly basis so that I can "rake
out the sandbox".
Dick Goulet
Senior Oracle DBA/NA Team Lead
PAREXEL International
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Blanchard, William
Sent: Wednesday, December 16, 2009 11:58 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: New Survey
Greetings listers,
I am trying to justify locking the developers out of our production
database but I need your help. We just moved to a new landscape because
the developers had horked up the last one so bad (production/qa/dev were
completely out of sync). Please take a minute or two to visit
SurveyMonkey and answer the survey I created.
http://www.surveymonkey.com/s/LQW738K
Thank you,
WGB
--
//www.freelists.org/webpage/oracle-l
-
This email and any information, files, or materials transmitted with it
are confidential and are solely for the use of the intended recipient.
If you have received this email in error, please delete it and notify
the sender.
--
//www.freelists.org/webpage/oracle-l
-
This email and any information, files, or materials transmitted with it
are confidential and are solely for the use of the intended recipient.
If you have received this email in error, please delete it and notify
the sender.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
