qstockmedia - Fotolia
Multivendor networks and disaggregated networks are unalike in many ways. For instance, the kinds of communities and ecosystems required to support the two kinds of networks are very different.
Multivendor environments require a well-written, coherent set of standards to operate correctly. There must be a community behind the standards supporting them to make certain the standards are, in fact, well-written to ensure well-designed implementations.
Disaggregation often moves beyond this baseline of standards. It requires a community to support open source components to foster the development of commercial products. It also requires the establishment of widely accepted interfaces between the components of the disaggregated system.
What both of these kinds of network engineering models have in common, however, is this: the lack of one throat to choke (OTTC). This prevents many network operators, particularly in the enterprise world, from moving down either path -- multivendor networks or disaggregation.
Solving network problems: When the network breaks
If it is 2 a.m., and the network is broken in a way that prevents business from getting done, everyone wants a number to call where a smarter and more experienced engineer will answer. Multivendor and disaggregated models seem to allow too much room for blame -- allowing the suppliers that should be working together to fix your problem to claim the problem is not theirs, but someone else's. OTTC offers what appears to be a neat solution to this problem.
Another problem OTTC appears to solve is the severe lack of, or high cost of, engineering talent. If you have OTTC, then you don't need to worry about hiring, training and potentially losing engineers who understand how to put an entire system together. Instead, you can hire some intermediate-level, or perhaps even lower-level, administrators. These administrators can take care of the daily operation of the system, and perhaps some low-level troubleshooting. Yet, because they are not expected to understand the inner workings of the system, they need little training. If they leave, they can be easily replaced.
Does either of these rationales stand up in the real world when solving network problems?
The first point to observe is you do not really have one throat to choke today. Maybe you have outsourced most of your information technology to some outside company -- certainly you can call this one company whenever anything goes wrong, right?
Perhaps, or perhaps not. Having a single company to call does not mean you eliminate the staff who know which department to call when there is a problem. You also need people who understand the technology well enough to correctly specify and manage the contracts. These people, within your own company, are a "second throat to choke," and will exist in anything beyond the smallest company, no matter how much is outsourced.
Challenges of single-vendor and multivendor networks environments
You will find there is no single vendor who will supply everything. Instead, in solving network problems, you will need to contract with several different companies to supply service on the various parts of your information processing, such as servers, applications, the network and other components. Direct experience over many years says there is still plenty of finger-pointing room in such arrangements, often combined with the "black box effect" -- each vendor's domain is effectively opaque to the internal talent trying to manage and mitigate a problem.
The result is multivendor conference calls that often turn into shouting matches and "I can prove" statements and counterstatements. The only solution, in these cases, is to have someone on staff who can sort through the claims, who is trained on all the subsystems well enough to bring them all together.
If the OTTC is really not, in fact, one throat to choke in terms of having a single vendor that can do everything, what about the second line of reasoning? Can you get by with less highly trained engineering staff if you have OTTC? Based on years of experience, this seems like the wrong way of solving network problems.
It is not that you can get by with a lower-level engineer, or one with less training. Rather, it shapes the kind of engineering talent you should be hiring and growing. Rather than hiring and training engineers who know each system in depth, you need to hire and train engineers who understand the system as a whole -- or engineers who know how to build systems, rather than components. This should not mean deeper or shallower, but different.
But is this really any different than the multivendor networks or disaggregated environments? The myth of disaggregation and multivendor is there is nobody to call when the chips are down. The reality is the exact opposite. Consider the OTTC model for a moment. Do you really think every vendor has an entire support staff in house, across their entire product line, at all levels of support? This is not likely. Rather, most of these companies rely on outsourced talent, funneled through a single brand, to provide the first few tiers of support. At the high end, these companies rely on the product developers for support.
There is no reason an enterprise could not rely on a set of support vendors or consulting firms for support in much the same way vendors do. There are, in fact, companies that specialize in helping operators manage multivendor and disaggregated network environments. Building a complete support system among many companies would be more complex than relying on a single vendor for all support, but it would likely be more flexible, as well. The in-house talent might need to be more capable, but this might improve the mean time to repair and reduce costs, as well.
Building a business and engineering approach
In the end, both of the OTTC arguments are not as clear-cut or simple as they initially appear. Given the nuances, it is better to take a more realistic view of how to support information technology systems. How can you do this?
First, ask this: What is lost, and what is gained? If you have not found the tradeoffs, then you have not looked hard enough. For each particular system, you need to evaluate how much the business depends on the system, what the impact of various levels of in-house versus outsourced support might be on the mean time to repair, whether or not the vendor can really support your implementation, and whether or not there is a talent pool—even a latent talent pool—available. The costs and benefits are not always obvious, but part of working in a digitized world is learning how to evaluate the tradeoffs here as much as you might in any other area of business.
Second, ask what you are doing to grow and nurture the right kinds of engineers in your own environment. The objection that is probably on your lips right now is: "But we have tried to find great engineers, and there simply are none." This may well be true—but why? Is it possible that our belief in the OTTC has caused us to stop building great engineers? The answer to this problem is not to rely on a vendor to supply all of your engineering needs, but rather to learn to grow and nurture engineers within your own organization when solving network problems.
But this only leads to a further objection: "I am not in the information technology business, so I have no role to play in creating and nurturing information technology talent." This is one excuse that never seems to be used for sales talent, business management talent or accounting talent. Businesses need to understand they do not need to be in the information technology business to rely on IT talent to thrive. Are you going to grow and nurture engineers you will eventually lose? Of course -- but you also grow and nurture great salespeople and leaders you eventually lose, as well.
Having one throat to choke might seem like an attractive proposition, like the sight of a wonderful oasis in the desert. The reality is, however, that the oasis is often a mirage, just like OTTC is often actually ephemeral in ways companies do not anticipate. Maybe it's time to stop using OTTC as an excuse and start thinking about how to build solid, genuine plans to support information technology in the real world.
Managing in a multivendor cloud
Understanding the true cost of hardware
Negotiating IT support contracts with vendors