Enterprise versus Provider?

Two ideas that are widespread, and need to be addressed—

FANG (read this hyper/web/large scale network operators) have very specific needs; they run custom-built single-purpose software in a very big scale. So all the really want/need are dumb boxes and smart people. … Enterprise have another view, they want smart boxes run by dumb people.

First, there is no enterprise, there are no service providers. There are problems, and there are solutions.

When I was young (and even more foolish than I am now) I worked for a big vendor. When this big vendor split the enterprise and service provider teams, I thought this kindof made sense. After all, providers have completely different requirements, and should therefore run with completely different technologies, equipment, and software. When I thought of providers in those days, I thought of big transit network operators, like AT&T, and Verizon, and Orange, and Level3, and Worldcom, and… The world has changed since then, but our desire to split the world into two neat halves has not.

If you want to split the world into two halves, split it this way: There are companies who consider the network an asset, and companies that consider the network a necessary evil. There are companies who consciously depend on the network within their product lifecycle and value chain, and there are companies who see the network as a consumer of money which is best minimized. This has nothing to do with “service provider” and “enterprise,” and everything to do with the company’s attitude towards technology and their future.

Second, the smart boxes/dumb people smart people/dumb boxes pairings is a false dichotomy.

All networks rely on having smart people design and run them. There are two ways you can access the smart people your network needs. You can hire a small group of smart people and allow them to work in the open source/open standards communities. This way you build a community that supports a lot of businesses, including yours. Or you can rely on your vendor to hire the right smart engineers, call them in when you need them, and hope they show up. Both models have positive and negative aspects, but the assumption that there is no cost sharing model in the realm of directly hiring smart engineers distorts the tradeoffs; distroted tradeoffs always lead to poor decisions.

Sometimes smart engineers can design things so you do not need smart boxes. Rather than hiring someone to build the smarts you will be missing by not buying from a vendor, you ask, do I really need this complexity in the first place?

The bottom line.

In my experience, most companies that use the “smart boxes/dumb engineers” line do not understand their business, their operating environment, or network engineering. This response normally comes from either a misunderstanding of the value of the network, a misunderstanding of the value of simplicity, or a fear of smart network engineers (they might actually push back against the application developers and vendors!).

It is much easier to scream at a vendor than it is to change the way you do business to take advantage of the network as an asset.

Another great reaction to this article can be found here