William:
I will chime in with another reason NOT to give administrative rights if your company exists in the United States: Sarbanes-Oxley. You can run into a host of legal issues and actually cause the company to be shut down or severely fined.
I don't want to go further, but administrators, like you said, are highly trained folks.
There is a possible solution if they want to have some sort of administrative control and that is the role of a subadmin. They are restricted by belonging to a certain group outside of being an administrator. Read up on it. We had to do this at a site where we fed information into a local Trouble Ticketing form and did not want this to become a full time task on a system that was centrally administered. We gave two on-site, trained folks sub-admin rights and that solved the problem.
James Mckenzie
________________________________
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Will Du Chene
Sent: Wednesday, September 06, 2006 6:13 AM
To: [email protected]
Subject: Re: Administrative Access
**
Koyb:
Ohh... Now that is a loaded question. I am afraid that you have just hit on a real sort of sore spot with me. I have seen places out there that have done something similar, allowing non-technical, non-programmer, non-developers with little background (or understanding!) with the application administrative rights to the installation. Frankly, that situation drives me nuts and makes the hair on the back of my neck stand. Believe me when I tell you that I am feeling your pain!
In the real world, your AR System administrator is the controller of such access. We're the gatekeepers and the developers. Typically, before even considering granting such rights to an account, the administrator would run the notion of granting the said rights to a project supervisor or some sort of other manager to get support for it - simply because of what the power that comes with the account can do. This is more or less a way of covering ones self in the event that the n00bie actually did something - ahem, bad.
If I were in your situation again, I would do what I typically do - set up a meeting with the powers that be and make my case. Explain to them the damage that this level of priviledge can do. Cover the facts and explain that - out of an organization of hundreds - there might only be one or two individuals that might have this role. Explain to them that the typical administrator has been doing this for years, and to actually do development work one has to be fairly knowledgeable about development (hopefully attended a class or two at some point) as a whole and have some experience with other forms of it.
If your counterpart is doing development in a production environment, that raises a really big, honkin', ugly-lookin' red flag. That's a no-no on a global scale and violates most of the change practices (and common sense) that I am aware of. This alone directly impacts your ability to support the system. You could explain that - if this other person does something nasty - you might not be able to correct it, or that recovery from it might involve recovering the database from it's last snapshot.
At the same time, you might want to give this other person the benefit of doubt. Perhaps their just doing what they are told to do. Yank their administrative rights from your production server and grant them on development. Put the new administrator back in the sand box where it belongs and let it play. This is not a bad approach at all because you are going to want ONE or maybe TWO (hopefully very seasoned) people with production access so that they can move changes over into your production environment, rather than letting it be a free-for-all in which cows can come falling out of the sky.
Finally, after you have made your case, and explained to them that they are on the path to making their installation look like something that came right outta H - E - double hockysticks and that it will be next to impossible to maintain, well... There are other opportunities out there. I'll fess up - I have seen a couple of installations that look really good on the outside, but - because some yo-yo higher on the food chain wanted something - looked like road kill inside. Yes, in those instances I did the best that I could, tried hard to fix it, and waited for something else. Ironically, my frustration level went away - AAahhhhhhh......
Best of luck with your this.
(Just more proof for my theory that managers are secretly a more evolved form of lemmings. If there is a cliff near by, and their buddies jump....)
----- Original Message -----
From: Koyb P. Liabt <mailto:[EMAIL PROTECTED]>
Newsgroups: public.remedy.arsystem.general
To: [email protected]
Sent: Wednesday, September 06, 2006 7:13 AM
Subject: Re: Administrative Access
**
Similar thought -
How is admin access given in most organizations? Who makes this decision? What is the experience for other listers? How would you handle it if you were responsible for the Remedy application, and some un-trained user is given Admin rights by management.
In my case, I am frustrated because I have an end-user (who is not a Remedy developer) making changes straight on production, and not taking the code thru development to testing, as I requested. And management has given a end-user admin rights to do this.
__20060125_______________________This posting was submitted with HTML in it___
__20060125_______________________This posting was submitted with HTML in it___
__20060125_______________________This posting was submitted with HTML in it___
