Costos de capital humano

To build our foundation, imagine a world much like our own, but where the concept of networking does not yet exist. Business is still done on computers, or something much like them, but no need has yet arisen that would require them to be connected to exchange data. On the rare occasions that data does need to be moved from one station to another, it is done by copying to removable media—some sort of wax cylinder, presumably—and walking it over to another party. After our post-connectivity enlightenment, this arrange-ment came to be called Sneakernet , as in your sneakers were the transport for the data.

Let’s say you work in desktop support, so you are a bit more technically inclined than the rest of the business. In between break-fix type work, you and Bob, a coworker in account-ing, like to exchange pictures of cats, sometimes festooned with silly captions. Not the highest-brow pursuit, but it helps the day go by. You and Bob have access to stations with scanners and printers, so you’ve been taking pictures at home and bringing them in to scan, edit, and print, and you exchange the print-outs via interoffice mail. One day, a new green initiative is issued from on high, strictly limiting your ability to use the printers for things that are not business-critical. You consider adjusting your workflow to use the wax cylinders, but this is not ideal—spare wax cylinders themselves are becoming harder and harder to come by. You think to yourself that there must be a better way.

You think back to a game you used to play as a kid, using two paper cups and a taut string to talk to a friend over a longish distance. You’d take turns talking into the cup, then mov-ing it up to your ear to listen for a response. Then your much smarter friend pointed out that if you built two sets, you could talk and listen at the same time—you talk into one cup, connected to a cup your friend held up to his ear, he talked into a cup connected to a cup you held up to your ear. You know there’s something to this concept you can use here, this idea of separate transmit and receive wires, crossed over to allow two parties to communi-cate. You set to work in your mad scientist basement laboratory.

The next morning, you bring in your results to show Bob. You install a card in each of your computers, connect them with a two-wire crossover cable, and install a new appli-cation that will allow you to send any file down the wire to the other station. You have brought along a few new cat pictures for testing, and they transfer from your computer to Bob’s without a hitch. You’ve built the first two-person network.

Bob is blown away, and thrilled to have his work hobby back. Weeks go by with the two of you happily shifting files back and forth, until Paul from HR looks over your shoulder and catches what you’re up to. He wants in, too. You pause to consider this. Even though Paul’s a little weird—he prefers dog pictures—you can see the value of having more than just two people connected.

4 CHAPTER 1 The Very Basics

cables degrades over distance, but the box will repeat the signal at full strength, doubling your potential range. You decide to call this box a hub , naming it after a children’s televi-sion channel you had on in the background while developing it.

The next morning, you bring in the hub, a card for Paul, and some new cables. By lunch time, you’re up and running. Each picture you select is indiscriminately beamed to the other two parties. But Sharon in Legal noticed you stringing cable up in the drop ceiling, and she wants in, too. Sharon and Paul don’t get along, though, and Sharon would like to be able to send pictures that might portray Paul in a less-than-flattering light. Obviously, she’d prefer Paul not receive these.

Back to the drawing board you go. To meet Sharon’s needs, your transfer application needs to become targeted somehow. But your hub will mindlessly repeat anything it receives to all connected parties. Maybe, you reason, the problem isn’t the hub, it’s the computers connected to it. The cards in your, Sharon’s, and Bob’s machines are all identi-cal. Maybe you could burn some sort of unique identifier into them, and then you could rewrite the transfer application to use that unique ID. You pull out your parts to get to work on the new cards, when it hits you—the hub will repeat everything it gets, so even if Sharon sends the picture directly to you, that data will still be repeated back to Paul. Well, since you’re changing the cards anyway, you’ll add a bit of programming to them so they will disregard any data they receive that is not intended for their specific ID. That should work. While you’re down in the lab, you figure you’ll make a bunch of cards. Since you don’t know exactly who will get what card yet, you decide to assign them numbers. You figure only 15 or so people in the company would ever need them, so you can get away with a two-digit identifier, so 00-99. Just prior to setting the ID on the first card, you think you’d rather not paint yourself into a corner, and double the ID field instead. Now your network could support up to 10,000 devices—unthinkable, but go big or go home.

You bring in the new hardware the next morning and round up Bob, Paul, and Sharon to explain the new system. You’ll get 0000, Bob gets 0001, Paul gets 0002, and Sharon gets 0003. This works well, for a while. Soon you have ten active users in your under-the-table network, and you start to feel the strain. Your users complain that it’s hard to remember who’s who, and Bob’s been complaining that he hasn’t gotten a single cat picture since you replaced his computer a few days prior. He thinks the rest of you are ignoring him.

The solution to Bob’s problem hits you right away—when you replaced his computer, he got a new card from the pile. He’s not 0001 anymore, he’s 0010. You’ll have to let every-one know this changed. But that will just further fuel the complaints that the numbering system is hard to use. What you need is a system that can accommodate friendly names, names people can remember. And if the hardware ID changes, that mapping of friendly names to hardware IDs needs to be able to be updated automatically, so you don’t have to go bother everyone.

Reinventing the Wheel 5

You create a lookup table , listing everyone’s name, a friendly name—you’ll ask everyone what they want to use for their computer name—and the network ID. You decide you will distribute this file to everyone each night, at least for now, until you can think of a better way to manage this issue of name resolution. The transfer application needs to be rewrit-ten, again, to support sending files to friendly names in addition to network IDs. You make the necessary changes and distribute the new file and instructions. All is well, for a time.

Awareness of your little project has started to increase. Your CIO has heard rumblings and demands to know what you’ve been up to. After you explain your work to date, he asks if the transfer program can transfer any type of file, or if it’s limited to just silly pictures.

When you tell him data is data, and any file would work, you see the gears turning in his head. He thanks you for your time and walks off.

A few weeks later, he comes to you with a request to connect every computer in your building—500 stations spread across multiple floors. He asks you to think about this and get back to him with the details. There will be challenges. Your hub has 16 ports, so that’s a problem right off the bat. You don’t see any reason why you couldn’t build a hub with 500 ports, but what if it failed? Everyone would be offline. And where would you put it?

There’s nowhere in the building where you could reach every station within the distance limits of your cables, and even if there was, creating and installing that many cables of such varied lengths would be expensive, in terms of both materials and time.

Well, if the request is coming from the CIO, maybe time and money aren’t going to be a problem, so you start by attacking the first issue, distance. One 500-port hub won’t work, but maybe two 250-port hubs would. Since the hubs are repeating everything they hear anyway, you figure you should be able to attach two together without a problem. Come to think of it, since everything is repeated out of every port, two computers should be able to transfer data whether they’re attached to the same hub or chained many hubs away from each other. Smaller devices should be easier for you to build, and easier for you to replace in the case of failure. After some head scratching and doodling, you decide on a three-tiered model. At the first, or core, tier, a single hub will feed hubs in the second, or distribu-tion, tier. You’ll put one distribution hub on each floor, and these will feed a third tier of hubs, an access tier. End-user workstations will connect to access hubs distributed through-out the floor. This will allow you to keep cable runs short and structured, and provide a cookie-cutter approach for expanding or deploying to new buildings.

You run this by the CIO, and he approves. You get to work deploying the new infrastruc-ture, and before you know it, connectivity is embraced throughout the company, and no one can remember how they ever got by without it.

6 CHAPTER 1 The Very Basics

Summary

Congratulations, you’ve built your first network. Go ahead and add “networking” as a skill in your LinkedIn profile. This has been an egregious oversimplification, sure, but it introduces the concepts we build on through these first few chapters. We introduced bits and pieces—applications, network cards, cables, and hubs—and we worked through some design challenges as we scaled. The next few chapters flesh out these initial concepts in greater detail.

Chapter 2