Implementing QoS is applying a temporary bandage to force certain traffic drop before other traffic when there is no more available bandwidth.
But dropping packets is NOT the goal, is it? When you deploy QoS you've admitted you can't afford to provide enough bandwidth for the demand, and that you've selected the flow of some users to be slowed or lost if the pipe becomes temporarily full.
Of course, you HOPE you're only dealing with a brief and temporary spike that's congested your pipe and caused the QoS buckets to start being used. But if you're looking at a continuously filled pipe, QoS is a short path to ensuring certain users are always disappointed by their traffic being slow or dropped. Ultimately they must reduce (or stop) their demand, move it to another provider, or they force you to add more bandwidth.
I read Fiefdoms, Silos, and Plumbing and felt that using QoS and its categories (presented in a manner that makes them seem very parallel to silos) in a topic that deplores silos was an unexpected slant. Extending it to absurdity, one might almost interpret that the expected improvement to an organization's performance (by the reduction or elimination of silos) could be extrapolated to predict an improvement in data flow might be achieved by eliminating the categories (silos) of QoS.
Of course that's not the author's intent or concept. But I somehow saw similarities between (bad) silos and (helpful) QoS. And the idea is absurd. Isn't it? Or is it?
Even as the need for QoS increases when available bandwidth decreases, so too do organizational silos develop and increase as the needs for more departmental specialization increase. This results in hiring or creating more specialized staff who are able to relate less and less to the specialization of other teams. Which causes more isolation and "silo-ization".
A vicious circle.
- Less available bandwidth causes more need for QoS.
- Greater specialization from each worker creates more silos and their expansion.
Suddenly the parallels between QoS and organizational silos become more related than one expected.
What other intuitive ideas could come from this, that might benefit an organization? Could there be a parallel between eliminating QoS and breaking down silo walls?
Can we eliminate or reduce the need for QoS, and find a parallel in the process to use for reducing or eliminating silos?
- You could throw bandwidth at the problem, thus eliminating the need for QoS. This can be an expensive proposition in some cases, but QoS is not used while there is sufficient available bandwidth and no congestion.
- You could also reduce demand on a network, effectively eliminating the need for QoS by taking steps that effectively increase the available bandwidth. But the challenge of training users to stop wasting bandwidth is daunting, and can feel over-controlling to employees. Many organizations simply implement content filtering to handle the most obvious and egregious wastes, as an alternative to herding cats (getting everyone to stop wasting bandwidth).
- There is a parallel between departmental silos and QoS categorization:
- Available network bandwidth is similar to available staff resources.
- Sufficient bandwidth reduces or prevents the need to implement complex QoS.
- Sufficient trained staff reduces or prevents the creation of departmental silos.
Put another way, if you have sufficient workers to handle the load, you can more easily remove silo walls. We know silos come down through knowledge shares and use of uniform tools like Orion. Adding the right amount of trained staff might be parallel to adding more bandwidth to a network pipe; the result is less and less need for the categorization (a.k.a. "silos") of QoS.
- Throwing bandwidth at a problem can be successful--but it may be expensive. Yet the end result is no dropped packets. The key is to more efficiently use intelligence to reduce demand, no matter whether than intelligence is QoS or content filtering or training users to stop wasting bits.
- Adding staff to handle load is definitely a successful path, and also comes with added expense--but it gets the job done properly.
So we see another parallel: Staffing levels are similar to available bandwidth.
Melding Human Resource terms with IT terms, one might realize bandwidth // resources // staff-to-do-the-job.
Complexity of applications seems to always increase, resulting in need for more specialized staff and more bandwidth. Reduce complexity and the silos start to become weak. Cross train staff so each can understand each others' tasks and work flow--and the silos could come down.