Careful with those invokations, Vijay.
> As we have seen before in previous lives, and I'm pretty sure stephen
> stuart will step in, normalizing "throw the ethernet over the wall"
> school of design just leads to an incredible amount of pain when trying
> to operate, run and actually document what you've got.
The various replies have largely covered what I would say; that it's
all about the OA&M.
Yes, in the previous life that you mention (known currently as "the
good old days"), some pain was suffered. If there is a spectrum
roughly described as:
- have no standards or documentation (and none of the pain of
developing, following, maintaining them) and spend all your time
doing discovery each time you have a problem to solve (so that
all of your pain results from having no operational consistency)
- have standards that you don't follow and documentation that you
don't maintain and constantly trip over exception cases (suffer
pain on both ends of the spectrum)
- have standards that are followed and documentation that is
maintained and achieve a high level of operational consistency
(this is widely regarded as "better")
then the pain that you describe came from moving along that
spectrum. The pain came from moving, not necessarily from the
direction that we chose. We moved in the direction that we did because
the goals that we set for ourselves demanded it. Hopefully the folks
still there continue to reap the benefits of that work.
Each organization chooses (whether consciously or not) a point in the
spectrum described above and operates there. They compete in the
marketplace without that choice being a significant differentiator; an
organization that lacks design skills might compensate by being able
to debug problems quickly, for example, such that externally
measurable metrics that drive purchasing decisions are roughly
equivalent. There is no One Truth; you try to make your organizational
strengths work for you to maximum benefit, while not getting tripped
up by your weaknesses. What *is* a differentiator is how well you
execute at the point in the spectrum that you've chosen.
That choice is made over and over again within the lifecycle of an
organization. The wheel turns, and administrations come and go, moving
one way or the other, using "the previous administration did X and we
must do Y" as justification for desired resources to travel in either
direction (or to stay in one place, with the appropriate label
engineering to make it look as though motion will occur).
All the while, the benefits and drawbacks of various aspects of
various choices will be debated on the NANOG mailing list.
There's an analogy to samsara hiding in there, for those that like
analogies. I'd elaborate, but it's time to take the dogma for a walk.
Stephen
