We have dozens of "multi-user systems." Our support staff will administer them as far as adding/removing users, installing software, setting up mundane things (telnet, ftp, ssh), adhering to corporate policy on things like security, OS patches, etc.

Then we go and put whatever we want on them. Support staff supports/maintains the parts that they put on, and disclaims all support on the rest (e.g., VNC server on AIX). Works ok for us, but as we are not only are software developers ourselves but also require root access for our own jobs, we get away with a lot ;-)

Anyway, that's the term we use for this scenario. We also have corporate-supported webservers that are managed by another group. And they require some annoying levels of paperwork to get into, similar to your concern. I stay away from those. Instead, I use a linux box running Apache, I use CGI::Application and HTML::Template, and don't even have the support staff help with my server. I take backups and copy them via NFS to an AIX box which is properly backed up ;-)

I agree with the 2 options above. But regardless of what option you go with, you will probably need numbers to get managment to sign on to either idea.

I would have each person in your group who has something like you script sit down and write a paragraph about what each script does. Make sure to add the approximate time the job takes to do manually and how often it needs to be done. Also add approximate time to develop the automated code that fixed it.

The benefits of outling each person's scripts are 3 fold.

1. You have numbers to show management that your team has automated time consuming manual tasks (doing the math of approximate time for each manual task times the number of times per week) and are saving them 'X' number of hours per week.


2. You show that your team is pro-active and forward thinking by automating manual tasks to save the firm money without having to involve the full-blown development teams.


3. The whole team gets its code out in the open so you can find repetative code and refactor it into reusable components.

Point #2 is important because it shows management that your team can code these basic time-saving scripts without having to bring in the full-blown dev team. Otherwise, you risk bringing this up to management and having it blow up in your face when they get mad that your team codes outside of the 'corporate development structure and guidelines', yada, yada.

Finally, I know your pain with what you describe. My group at work has something along the same lines. It is a website that runs on a 'Dev' webserver and hosts description of our batch cycle jobs and allows the team to enter failure resolutions so hopefully the next time the same job fails, it is already documented on what to do. We also use this webserver for any other ideas that make our job easier (team documentation, notes on how fill out red-tape paperwork quickly, etc).

Since we host it on a 'Dev' machine, if it is down for upgrades or hardware failure, we are out of luck. But this also gives us the ability to make changes to the website whenever we want without having to go through the corporate change procedures. All code for the website is in the corporate source control system so we can restore if there is a drive failure on the box (this is important as it has happened in the past).

What each group runs on the tool box is up to them. There have been a lot of 'little apps' developed here. Some of them have proven very useful to other departments. Word spreads rapidly at the grass roots, and the Central IT Department has had to break-down and accept 'wide-spread use of User Developed Code' in lieu of the Program Justification Procedure documents.

Also, Central IT has a policy that all applications will be written in the Corporate Standard Language -- Java. When they build a solution for you, that's what you will get. No Exceptions.

Building a little Perl script that reads the line quality numbers from the department edge-router and creates a web-page showing the current circuit load along with quality-of-service metrics -- one Saturday afternoon.

Getting your code accepted nine months later as the Corporate Gold Standard for Line Monitoring -- $2,000 bonus.

Watching the Central IT Sr. Tech trying to translate the Perl into Java, and giving up because 90% of the code is in two statements: 'use CGI;' and 'use SNMP;' -- Priceless.

Better is to get two servers. The first is the Tools Development box. The second is the Production Tools server for tools released to a wider internal community.

See if you can try it out with some older kit running linux or something to proove the case without spending too much.

Google seems to get some hits for that terminology as well.

HTH

In my corner of Corporate IT-land, that isn't what "staging" means. Here staging is where new applications and new changes go when they're ready for their last round of testing before hitting production. Therefore the staging systems need to be near-replicas of the production environment, and access to them is almost as tightly controlled as production because you don't want random users installing or changing things that might bias the testing one way or another. We actually don't have a term for what Cody Pendant is asking for, which is a shame really, because it sounds like a good idea. Here what ends up happening is that people end up messing around with app development boxes and no one has any clue what's on them.

Or you could just pick an incomprehensible jumble of letters and numbers and use that. For added points don't put the name in DNS - have each user keep it in their /etc/hosts file. Good times.

-sam