X-no-Archive:yes Been there, done that, have the life vest from the sinking ship. Was shown large red notebooks chock full of system documentation. They weren't enough. I'll give you that good documentation is as necessary as good people, and I should have mentioned that as well. OTOH, even good documentation is hard to deal with after the brain trust has left, or mass turnover in your words. Mergers and outsourcing have their own problems to deal with for good documentation and good people policies. OTOH, one thing that leads to this anarchy is inane procedures that get ignored because developers have seen that they add no value. I've seen a shop were there was a grey market for version control work arounds, and the existing version control system was so badly implemented that it was later replaced. I will gladly produce audit trails, and document my work, and sit down and explain to genuinely interested parties, but am frankly sick to the teeth of spending a few hours here and there over the course of months, to accomplish ultimately very little, because it takes people in very different groups with different agendas and little trust or respect between them (and in our case, working for different companies, but outside of a normal outsourcing or consulting relationship). I do not see how discouraging cooperation across such functions, especially within a company, in the name of audit standards is going to improve that situation. And I find Wirt's argument persuasive: that the 3000 can be found in businesses with no IT group, and that this is a good thing, to be greatly encouraged. Computing can be a low maintenance activity. Where a company has an economy of scale to have such specialists, and to organize them into groups with some functions, does it necessarily make sense to prohibit someone from performing some function because they also have other responsibilities? I am loathe to think what it would take to write and maintain (system programming) a secure (security) ftp job (networking, application development) that runs as part of the production schedule (production support, system administration), if there is no one who actually understands more than one of these areas, and can think thru all of the implications that activity in one area has on another. FWIW, I do recall a brief article discussing RAD as Rapid Application Death, where the author suggested that these hacked up 1.0 releases that would be replaced by another cheap product's 1.0 release, none of which would ever see a 2.0. > -----Original Message----- > From: Richard Gambrell [SMTP:[log in to unmask]] > Sent: Wednesday, December 30, 1998 2:40 PM > To: [log in to unmask] > Subject: Re: audit issue > > Then one needs to consider mass turnover, mergers, outsourcing, etc. What > happens then? Good (documented - and followed) procedures at least > maintain > the integrity of the source code and operational scripts, etc. But, this > presumes the value of maintaining those systems through time. <snip>