Re: OT: Is there a word for a semi-official server?

I sympathise with your position, but you need to decide if it's just going to be a central repository eg CVS for 'unofficial' scripts/DB schemas which will be backed-up in case your 'active' boxes break, OR you want it to be an active central server ie running the DBs & scripts.
The 1st option they might go for if all they have to do is set it up and back it up.
The 2nd is less likely as someone will have to actively manage it eg be a DBA; you can't have multiple DBAs, 1 for each dept, at least not for the situation you are describing.
It would also take more active management in terms of users/perms & as you mentioned Modules....
They're not going to like that, unless you can do some v smooth talking.
BTW, no I've never heard of a similar situation ie un-official server. The nearest would be a departmental server that you or someone is willing to administer, assuming your boss will allow you the time...
Good Luck
Chris

Comment on Re: OT: Is there a word for a semi-official server?

Replies are listed 'Best First'.
Re^2: OT: Is there a word for a semi-official server? by etm117 (Pilgrim) on Feb 15, 2006 at 08:57 UTC
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. 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. 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. 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).	[reply]

Replies are listed 'Best First'.

Re^2: OT: Is there a word for a semi-official server?
by etm117 (Pilgrim) on Feb 15, 2006 at 08:57 UTC

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.

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.

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.

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).

[reply]