- 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.
"Ok Everyone listen up, we gotta test this thing for the next 2 years, so start drinking up"
Or maybe, we could just have little milestone races, first one to Mars, Saturn, Andromeda I, Kashyyyk
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
Oh, ahem, btw Happy Birthday Internet!
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
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.
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/ )