I recently talked with a customer about selecting an approach for network automation; a new technology for them. I did some up-front planning, made some notes, and then we talked for an hour. The result was a small set of decision criteria that I thought would be useful to the busy corporate IT / network executive. The process is much the same as you would use for any important decision regarding the adoption of new technology.
What is Needed?
We started the conversation with a discussion about defining realistic goals for their organization. We talked about identifying the functions that were driving the need for network automation:
- Initial provisioning for a big rollout
- Enabling agile configuration management to track dynamic operations in the IT server space
- Performing OS upgrades to close security holes in network hardware
- Verifying operational correctness of the network against the network design documentation
- Configuring and controlling of hardware from multiple vendors
Identifying what they needed allowed us to establish some boundaries around the problem space. It is just as valuable to know what you don’t want to accomplish — non-goals — as it is to define what you want to accomplish. By setting goals, you can create metrics against which to measure success.
Is the Organization Capable?
The next phase of our conversation established whether the organization could create a network automation system. How many people could be put on the task? What time frame was needed? What is the budget, both in time and money? How big is the network, in terms of the number and variety of network hardware boxes? What other projects will not happen (i.e. will be delayed) because of this project?
We were able to use the knowledge of the goals to estimate the size of the tasks. That let us get a handle on what the organization was capable of doing.
Possible Approaches
The discussion then turned to possible approaches. We considered three paths:
- Build it yourself using open source software packages
- Purchase a commercial product
- Hybrid – build it using consultants and open source software packages
We spent the remaining time talking about the risk / reward tradeoffs of each approach. The goal was to gain some preliminary insights into each approach, not to come up with a solution (this organization didn’t need to make an immediate decision).
Conclusion
What was the final decision? Nothing yet, but they have a greater understanding of the problem space from which they can do more thinking and research. It gave the organization information that they had not previously considered, which is exactly what they hired us to do.
Consulting with trusted advisors is one of the functions that we provide at NetCraftsmen. The next time you’re trying to decide on a specific approach to a problem, consider getting some thoughts from one of our senior staff.