Add a Comment Now - We Want to Hear From You
Adapted from Joel Trammell’s Symposium 2008 Speech
The mental model of a network for most people, even a lot of people in IT, is very simple: Build the application, and roll it out to the client boxes, through the WAN cloud, via the server. That’s the view of the world.
Reality looks a lot more like spaghetti. There are all these devices, sometimes thousands, sometimes tens of thousands, in that infrastructure. My favorite story is that when one company went into gain a bid on a Navy/Marine Corps Project, which was the biggest government IT contract that had come up in years, part of the scope of the project was to reduce the number of applications on that Navy/Marine Corps network to 5000 applications.
But when they asked the Navy/Marine Corps how many applications were on that network at the time, they had no idea. The company, along with rival bidders, had to make a guess – and 25,000 sounded like a good number. After all, there was no possible way that there could be more than 25,000 applications on this network, and so, they made that assumption and bid on that basis. Now last I heard, they got over 105,000 and were still counting because every single Navy base, every single ship, every single Marine installation had developed their own suite of applications independently of all the others.
I remember when we first went for funding, we talked to a local VC firm here, and we talked about how we were going to solve performance problems in large networks.
And, the first question we got back was: “Well, it’s great that you're going to address all these performance problems they have, but what are you going to do the next month?”
They didn’t understand how the network is dynamic - there's things changing all the time, any user out there can probably mess it all up, and it's not just a process we do once and look at, it's a process that we do over and over again.
In many ways, a network engineer’s job is really protecting the infrastructure from all these changes that are occurring in the environment.
I surveyed my team and asked them what problems we’ve been solving for customers. We started listing these things on the whiteboard, and as we put them all up on the board, we came up with a few specific themes – a few specific problems that keep occurring.
Over the course of the next several posts, we are going to explore some of those problems we came up with and how they can be addressed. What I’m hoping to do isn’t so much for education – most of Network Performance Daily’s readers are already aware of this information. But hopefully, this will give you some ability to illuminate the value you give to the organization, to maybe help explain to the “higher-ups” exactly what types of problems you solve, and what kind of issues they should be addressing.
