A Boston Technical Recruiters Blog

The NAT should be a choice of individual network managers.  Given the benefits of security and privacy that a NAT affords to the user there are plenty of workarounds for defeating the ill effects NAT has on certain protocols such as FTP. The article in Wiki stated that dedicated internet servers coupled be placed outside the NAT zone to allow for undisturbed end-to end connections, while behind the NAT screen the administrator could do what he pleased. It was also suggested that IPv6 will replace NAT, however I do not think this will happen given NAT’s popularity with vendors such as CISCO and its natural firewall properties that most people do not suspect even exist. Why be open to the entire world with a global network when you can have a NAT DMZ essentially protecting you against everyone who would ping your ports and seek access through the numerous Windows vulnerabilities?

 Share

Wireless will never completely supplant wired communication because there will always be walls, tunnels, weather, interference, dead spots, and other generally unpleasant inclement conditions that contribute to the “Can you hear me now?” syndrome.

Wireless communication is still too nescient to replace hard wired communications reliability and security. While fiber optic lines are almost impossible to tap, wireless communications are not as secure or reliable as wires. Wireless may be great in an office setting, but if you look at a WAN scenario, a signal would have to complete too many jumps in order to traverse large distances using an inordinate amount of power and establishing an unreasonably high service cost.

Some cities have gone completely wireless by installing Wi-Fi city wide, yet no one has mentioned that such amounts of microwave radiation may not be very healthy in the long run. Also, due to the relative short range of existing wireless devices, more such devices need to be deployed to create “hot zones” where dead spots are not a problem.

Looking into the future, I cannot image that a wireless device will ever be able to carry the same volume of information, at the same speed, reliability, and security as an optical cable.

 Share

The balance needs to be established on a case by case basis. One enterprise may find it useful to have a thin client infrastructure if they are running a high volume of highly repetitive tasks that rely on the same application or database to function as for example a call center.

The thin client is a good security tool as it would lock a client to have only the software that was necessary to access the server and would not allow users to change settings or adjust features that may open security gaps. Productivity may be increased if workers are thus forced to work within a single application.

The scalability of a thin client environment is also much improved in an environment where the server would not need to handle too many different applications and everyone is using the same portal to access the host. Yet you could add many clients to the server without much cost. The cost of upgrading the host may be larger, but the trade off in the greater agility would offset this cost.

A more decentralized architecture allows for a more robust development environment where each client has the applications and the data storage that the particular employee needs. If the client is working remotely, it may not be advantageous to transfer large volumes of data that can be stored on the client and use the server for smaller messaging needs, while leaving the heavy processing on the client machine. Backups are also important while it may not be efficient to store everyone’s work on a central server as opposed to individual desktops. Redundant backups between the client and the server ensure that the loss of one system will not halt the business process.

Thin – client architectures may be reminiscent of the old mainframe, but it seems they play a more fragmented role even in a highly centralized environment. Instead of having one mainframe do all the lifting, there are several servers that are working with clients, delivering data that the particular group of clients needs, rather then having every computation performed by the same machines.

 Share

Scope, Time, And Cost… these should be relatively self explanatory and are fundamental to all project management.

 Share

This is when you break down the project into smaller more manageable parts.

 Share

Scope creep is the result of project requirements growing as the project progresses.  The project manager must be aware of any extra RFC(request for change) requests coming in and carefully manage the budgetary and time consequences of these requests. Uncontrolled scope creep can doom a project making it unwieldy and running it vastly over time and over budget.

 Share