>To soften this a bit, I strongly recommend the reading of Eric Greenberg's
>Network Application Frameworks
>
>Eric is another one of those guys who used to post here a lot. ( haven't
>heard from him in a few months ) He and I struck up something of a rapport
>when I discovered he and I shared the concern about fingerpointing in
>troubleshooting exercises. For example, in his Preface, he lays out a
>scenario in which "The company's sales staff has called a meeting with the
>IS department to discuss the increasingly poor performance of their
>worldwide sales processing application." Having been called to meetings like
>this, in more than one organization, I learned very early in my career how
>to take steps to determine what the real problem is, not the apparent one.
> one of the reasons I find Howard's writing so interesting as well )
>
>The point Eric makes, and one all of us needs be aware, is that there are
>many reasons that network performance can be negatively effected. Cisco
>places quite an emphasis on protocol behavior in its design certification
>test. Probably because in the experience of Cisco, thorough understanding of
>protocol behavior goes a long way toward designing good solid networks with
>good performance. We see questions regularly on this group and elsewhere
>asking questions, the answers to which come from understanding how NetBIOS
>over TCP or certain UNIX functions operate. Let alone IP itself.
>
>In return, my strong opinion is that folks who do not spend the time
>learning how networks work, and how the different parts interact, who just
>want to be router jockeys, will certainly find themselves at the lower ends
>of both the pay scale and the promotion scale. I know I am truly impressed
>by a number of people I have met through this list, people who have taken
>the time and put in the effort to learn Unix, and Linux, and Microsoft and
>Novell. Folks like these have offered a lot of good advice and good insight
>to problem solving questions that appear here regularly.
>
>Chuck
No argument about what you're saying in the small to medium
enterprise, or resellers that deal with this market. If you are
working with ISPs, telcos, or enterprises large enough to effectively
be their own ISP, the application protocol knowledge is much less
important. Believe me, there's more of a shortage of people with a
solid understanding of Internet exterior routing than there is for
people who know both basic to intermediate IP plus Microsoft or
Novell.
UNIX user knowledge, not necessarily system administration, does tend
to be important in the provider environment, where Microsoft has not
penetrated nearly as far.
No knowledge, of course, is useless. I've just spent a couple of
days involved with planning network products for, among other things,
third generation wireless. Some knowledge of image transfer, HTML and
XML, WAP, etc., certainly was relevant there, although what was more
important than the application protocols was their traffic
characteristics and quality of service requirements. I did get
extensively into network infrastructure such as DNS, address
assignment, etc. Now, remember I am working as a product architect,
so my day-to-day work will differ from people more operationally
oriented. On the other hand, I have to specify products that the
market will buy.
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
