The Best Decisions
Business or Technology?
A long time ago, when I worked for a major vendor’s escalation team, I was called into a customer to help them move from one routing protocol to another. We spent some time looking over their network, discussing how best to approach the problems they would probably encounter, how long it would take to make the change, and many other issues involved. Finally, over lunch, I asked why they were planning on changing routing protocols.
“Because we are studying for a certification, and none of us have any experience with the protocol we are switching to.”
While this example is a bit extreme, it illustrates a widespread tendency in the information technology world nicely—we often spend more time thinking about technology than we do about solving business problems. Another example—a recent study from a large cloud computing organization stated that companies with “on premises” data centers lag behind companies who exclusively use public cloud services. The notable question the survey did not ask was: is this “latest technology” necessary for the business? Does it really add value?
As engineers, it is all too easy to become wrapped up in a new technology, whether it is a new piece of hardware, a new protocol, a new piece of software, or whatever else is presented as some large show. This tendency is no different at the upper levels of the information technology organization; just replace the latest show or presentation with the glossy cover and pages of a magazine targeted at “the decision maker.” We all too often forget RFC1925, rule 11: “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.” The corollary to this rule, as noted in the RFC, is: “It is always possible to add another level of indirection.”
If you are going to put business first, what should you look for in a technology or a solution?
First, the solution should solve the problem at hand. This might seem obvious, but it is far too often true that engineers choose a technology because it solves every requirement, rather than this problem. Choosing a technology that can solve every problem that can ever be imagined seems, at first, to be a good way to future-proof your network. If a system can solve every problem you can imagine, then there should never be any reason to upgrade. There is a difficulty hidden in this view of engineering, however. The first part of this counter is that all systems have natural lifetimes. No system you design today will survive “forever;” it will be replaced. The second part is that such all-encompassing, “solves every problem,” sorts of systems are individually complex. Given you will never have just one system, combining multiple very complex systems will create a system that, in many cases, reaches beyond human understanding.
Second, the solution should be the simplest possible solution to solve the requirements. Simplicity and elegance are, I find, the most underrated engineering values. A single simple solution that solves 80% of every problem is going to be a better solution than a set of overlapping, interacting complex solutions, each of which solves one problem perfectly.
Third, the solution should be flexible and extensible. This might seem to run counter to the first objective, given above, which says engineers should focus on solving the problem at hand, rather than trying to solve every imaginable problem (or every corner case). These two are not, however, contradictory; rather they are complimentary. Solutions should be focused on solving a set of well-defined problems, but the list of problems should always include “this system can be extended to solve other problems we haven’t thought of, or we have intentionally left out of scope.” What the first point is warning against is trying to build or deploy something that solves everything today; what the third point is warning against is building something that can ever only fulfill the immediate requirements, without considering future requirements.
Returning to the top of this post: the goal is not to deploy something new, or exciting, or that seems like it will future proof your network against every possible requirement. The business should drive the problem definition, with engineers pushing back to define a small set of problems that can be solved within a fixed realm of time, and with well understood technologies. Both sides should be realistic in understanding that no technology lasts forever, everything needs to be extensible, and even well-defined problems that are too widely scoped are bound to end up in a complexity wormhole.
Find the business problem, scope the business problem, solve the business problem. When done, repeat.
There are no future-proof technologies or solutions.