In a recent podcast from pauldotcom.com the security touched upon this subject a one of the more popular methods of now (amongst that group) seemed to be to use:

- Truecrypt (http://www.truecrypt.org/) to encrypt your data.
- Keepass (http://keepass.info/download.html) for password management
- Dropbox (https://www.dropbox.com/) to keep your data passwords secured in the cloud.

Truecrypt and keepass both support strong algorithms for management of data and dropbox allows you to keep your info synch'd no matter where you are.

And you can stay flexible with your OS of choice. ;)

The very first power generated by the prototype was used to boil a kettle to provide the guests with hot water for refreshments at the opening ceremony. The prototype has a limited production capacity and will be used primarily for testing and data validation.

"Ok Everyone listen up, we gotta test this thing for the next 2 years, so start drinking up"

Quick, everyone start sharing Barry Manilow songs.

I guess it depends on the RPG game? I think for most of the 'single' hero games link Adventures of Link or games like that on the Nintendo, Super Nintendo, Genesis and what not you may be right. But in the ones that usually allow you a party to form such as the Might and Magic series, Wizardry, and for now of my experiences on LOTRO, I find that usually I die or the party wipes through a failure of strategy, ie not enough heal postions, not using the right spell at the right time, etc etc, and I guess it was from that vantige point I was thinking.

Not to oversimplify the article as it interesting but this seems to be in line with learning through failure. Or better, understanding that failing is one of the greatest learning tools we have, no? Numerous books from 'Think and Grow Rich' to 'The Power of Positive Thinking' and just endless links to white papers all documenting this as an important concept to understand as we reach adulthood as for somewhere in between adolescence and adulthood many people seem to loose or forget this concept.

Kumbaya my Lord, kumbaya...

I never really got a good idea of what constitutes the 'winner' in the space race. I say as the U.S. was on the moon first we declare the U.S. the winner and get on with working together collectively as a team.

Or maybe, we could just have little milestone races, first one to Mars, Saturn, Andromeda I, Kashyyyk ;)

Ok, now that I have my flamebait out of the way. Looking forward to what will be the next milestones.

1) Speed, the hunger for data transfer will definitely keep increasing so backbone upgrades to support 100Gbit and 1Tbit speeds will be coming. On what medium, that is a good question of which I believe fiber's potential has not been even remotely reached yet.

2) Input method to computers, I think this method will stay with the keyboard for sometime but like all input methodologies, it will eventually get improved upon. Currently we are limited to the speed of our fingers which is nowhere near the speed of our brains, so bridging this gap I feel will be a major overhaul at some point in time, say 20 or 30 years? (Hopefully before I die, I would love to see it ) Anyone remember the scene in Star Trek IV where Scotty talks into the mouse thinking its a mic? LOL
Maybe something along the lines of Minority Report would be the next step combined with voice

3) Identification technology as well. There are already companies that are working towards doing face recognition as you walk by to tailor ad's to you on their monitor as you walk by. One example here (http://www.designer-daily.com/billboards-are-watching-you-2566)

4) And definitely wireless communication tied in with wireless power. There is already the project set in motion to put solar panels in orbit to beam power back to earth as well at wireless power through resonant coupling continuing to be researched. I think the combinations will help us eventually spreading our wings from this planet and enable the transmission of data from deeper and deeper parts of space to take place. Maybe playing MMORG's from the moon will be possible in the near future :)

Ohhhhh! So THAT'S where Al Gore was on September 2nd 1969. [sic] Now it all makes sense being that he was the brainy type, that he is also a key figure in leading us to salvation on Global Warming with the 'Inconvinient Truth'. Everyone, quick to the cap'n'trademobile. (na na na na na na na na Goreman!)

Oh, ahem, btw Happy Birthday Internet!

Andrew, your question is not dumb and I hope this reply helps you in some way. I am currently also a manager for a company that has a dev dept. that maintains proprietary code. I have been here long enough as well to grow the I.T. Dept. from when they were small and had little controls in place, grew my staff and hired security types to do gap and risk analysis to help establish proper controls, and also back down the hill with little to no staff again and having to vendor everything out.

My advice to you would be that it doesn't really matter whether you vendor out or hire internally, thatâ€(TM)s a cost based decision that should be made based on your company's need. (i.e. are you growing with many projects or downsizing and have a freeze on all projects) Usually during the expansion phase and stabilized phases of a business you will hire as it typically is cheaper and more beneficial because in-house developers and engineers (usually) take pride in their work and if you are a good manager, they will always go the extra mile and do the little things that really help make a network run its best. You'll have to do cost comparisons and analysis to see what fits your needs.

What does matter it appears from your post is your IP, source code, and customers. That is just information and any infrastructure engineer does not need access to that info to properly manage and maintain your network and systems. So concentrate (if those items are deemed super secret ;) ) on what controls can and feel you may want to put on place to allow only those who need to know work with that data.

Your IP info can be encrypted to those who only need to know the info and still be managed by an engineer. Some examples might be going down the road of AxCrypt, Truecrypt, or some kind of PGP based type of setup. Your source code can be maintained in a source code manager like subversion, vss, or CVS. And the same with your customer information, you should be able to manage it in such a way that your engineer does not have access, or can see the information, but access to manage it and let them do their job. Again, you'll have to do cost benefits and risk analysis that dollars spent provide true value and not a feel good value. Either you or a consultant can do a Quantitative or Qualitative Risk Analysis to help give a clearer picture of your risks.

As also pointed out, most engineers that I have worked with, really don't care about data and just want to do their jobs. But in the end youâ€(TM)re the one responsible for ensuring you point out all the risks to the business and let them decide what do to from a dollar standpoint. Cause in the end, if there is an incident and you failed to identify it to the business, that could be your job.

G/L !

Read a lot of good posts and ideas so far here. From my perspective, the most cost effective solution for you and the business is, you need a backup engineer for in case you do get hit by that bus. Having a person knowledgeable enough about your network to keep it running in the event you are incapacitated for a length of time is by far the most beneficial, if for no other reason, because of the quick turnaround time they can come in and take over vs. company looking for another engineer, and the time it takes to learn the network and scrounge threw docs you created.

Very few documents are actually that meaningful if the engineer is halfway competent so as others have mentioned, no need to go documentation crazy. There are key docs I feel though that should be created and maintained and have been mentioned above.

1) Passwords, I cannot stress this enough, get all accounts privileged accounts and service accounts documented with passwords and secured somewhere (preferably off the network, such as a USB key with the data on it in a safe) as without this, it can be a very ugly scene.

2) Next, overall, logical and physical network diagrams are paramount. If done correctly can make troubleshooting a breeze, and a nightmare if not done correctly. One link that I like is a reference to a best practice guide about the Cisco 4000, 5000, and 6000 series equipment found here ( http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml#management_cfg ). Go to the network diagrams section and review the overall, physical, and logical section. Create your docs with this as a guide and any engineer who may have to troubleshoot the network will love you for it.

3) The answer to what 'other' documents should I create? Comes from you. Knowing what you know about your network, pretend you are coming into the network for the first time, and ask yourself, what I would wish I knew about this network? Make a list of your business critical functions where people would be screaming if the service was inaccessible. Document what would be useful info in a DR scenario of recovering the service. This leads me to the last doc I would recommend as useful only as an insurance policy for the business.

4) A procedural document of how to recover various business critical services. Again, key focus is on business critical, business users or clients will care less about non business critical services or be a lot more forgiving. This can assist greatly an engineer if good recovery procedures are documented, especially in area where customizations have been done (i.e. scripts and what not)

The other biggest important thing you should do is manage the businesses expectations. Talk with the business to get feedback as to What are the business critical services and document them. Next, get your Service Level Agreements ( SLAs ) agreed upon between you and them. And make sure you can meet them. If not, get a projects/tasks list together of what needs to be done so that either A) the business will fork over cash to meet agreed upon SLAs or B) they will accept the current SLAs.

The SLAs are important because it will force you to take a hard look at the network to see if you meeting their expectations. That is really what it all comes down to. When I.T. does not meet expectations is when the business gets all bent outta shape. Manage the expectations and get your SLAs agreed upon for restoration of services and you will be ok.

One more link that can help in ensuring you can meet SLAs is getting your RTO and RPO defined for you business critical services. Here is a nice easy link that talks about this that should help you.
( http://findarticles.com/p/articles/mi_m0BRZ/is_3_24/ai_n6017376/ )

Good Luck!