| **
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....)
__20060125_______________________This posting was submitted with HTML in it___ |
- Re: Administrative Access Will Du Chene
- Re: Administrative Access Barber, Dave
- Re: Administrative Access Timothy Powell
- Re: Administrative Access Pierson, Shawn
- Re: Administrative Access McKenzie, James J C-E LCMC HQISEC/L3
