Turn Network Engineering Right-side Up

The network engineering process in most organizations is usually upside down. Network engineers are more often involved in provisioning and then perhaps go back and address the design.

Consider an auto manufacturer. The engineering department designs an automobile or series of autos, with various options. This design doesn’t apply to any particular auto, but it is abstracted to address all autos built using that design. The manufacturing then fits the factory using that design and builds a variety of autos in different colors and options each with unique VINs.

Consider a software developer. They develop an application with certain requirements and features and develop it to run on a variety of platforms. They then use an installation packager to deploy that application to the various platforms and configure it correctly.

Have you ever had a problem with your car and brought it to the shop? Did the mechanic first go over the entire auto to make sure it was built correctly? Was there ever any doubt that the auto was built according to the design just like all other cars of that make and model? No. The repair center can look up the model/VIN and determine exactly what parts and options were used on that particular auto. The design is standard and each auto has information pointing to the design. Have you ever had the repair shop tell you that a particular part needed to be replaced with one that had different specifications (change the design) to repair your problem? Of course not. Have you ever had a problem with a software application and called tech support? Did they ever run an application to ensure that it had all the correct libraries and executables? No, they ask for the version number. The version number tells them what design was used to create that specific instance of the application.

Why then, do network engineers have to constantly check routers and switches to see if they conform to standard templates (if standards actually exist)? Why do network engineers build (provision) the network then go back and try to put together a design (in the context described above)? Why does tier three often reconfigure (change the design) of a network device in order to resolve an incident? Why can’t many network changes be tested without building the entire production network in dev? Because the production network is the closest thing to a design that exists. The fact is that the common approach to network engineering is completely backwards – and this paradigm is so common that it’s rarely ever questioned.

Does anyone remember how MS Windows networks were built and maintained 15 years ago? Each computer (desktop or server) was built individually using an install program. Each was managed individually. This caused a great deal of diversity and was very labor intensive. Two significant changes that completely changed this were system images and active directory. Using these two design constructs the software could be centrally managed with much more consistency and less labor. It improved system availability and reduced TCO.

Would you like to learn how to design your network and then provision it using the design? Would you like some inexpensive tools to assist in that process?

Contact us to find out how.



Leave a Reply