Blog

From a high level, managing your IT infrastructure can be boiled down to 5 basic steps:

1. Knowledge gathering
2. Create standards based on that knowledge
3. Implement the standards in a consistent way
4. Maintain consistency while managing change
5. Document heavily

Knowledge Gathering

Of course, it’s not as easy as all that. Gathering knowledge can be a big challenge….too little information to base your ideas off of and you may be missing critical configuration for security, etc. Too much information and it’s easy to get paralyzed by it.  Security is critical but so too is functionality obviously. Experience is very helpful in determining what becomes part of your organizations standards and what gets left out. For example, reading through Cisco documentation for an ISR router configuration from scratch, if you’ve not configured a Cisco router before, is extremely daunting. There are configurations and commands available that most engineers have never even seen and are most likely not needed in typical environments. Only through experience can you determine what your organization really needs and what it doesn’t. 

Create Standards

This is one of LookingPoint’s strongest value adds in my opinion. As we get to see all of the similarities and differences between configurations at different organizations, we constantly tweak our own ‘best practices’, choosing things we like that increase security, increase the clarity of the configuration, etc. When things happen like older commands being deprecated, new versions require interim upgrades, and so on, we typically get to see that and come up for a plan for handling that before many businesses who have other focuses (their own business goals for example).

It’s interesting (to me anyway!) to see how our standards have evolved over the years, taking the cleanest and the best configurations as we go.

Consistent Implementation

Read any marketing material for IT infrastructure components these days and you will likely read about Policy-based management, profile-driven configurations and the like. Clearly, these products are trying to solve a problem many customers have, which is consistent configuration across devices. Things like Cisco DNA center are amazing products that do cutting edge things that are beyond the scope of this article, like ‘intent-based networking’, but a big reason larger companies like these products is that it makes it much easier to maintain consistency across the organization. 

Having clean, consistent, configurations is hugely important for an engineer. With Cisco CLI for example, it’s like reading code, so it can take a while to grasp what the intentions were (this service policy references this class map that matches this access list and it’s applied here, etc.)  Having things labelled, using remarks when needed, using descriptions with relevant information all make the engineers job easier when troubleshooting. Hopping from device to device and them all having the same feel, the same descriptions and names, just feels more natural and things just make sense. 

With a lot of the companies we work with in the SMB space, profile driven management platforms can be overly-complex and maybe too expensive for their needs. Fortunately, a policy is a policy whether it is pushed to a device through a management platform or just documented/templatized and implemented by an engineer.

Maintaining Consistency

With networks on the smaller side, implementing consistent configurations is not really all that difficult, however, maintaining consistency through times of change  is a difficult task for any organization. Change management processes can sometimes feel overbearing to IT staff, but they can be very useful if used for peer review of the proposed configuration, implementation across applicable devices, and documentation updates to ensure that the job is done end to end. Policy-driven management platforms do make this easier to control, but it is possible to do this manually with a little help from our monitoring tools. We monitor changes and are alerted to them, which triggers a proactive ticket to be created and an engineer assigned to review and document appropriately.

Document Heavily

In my experience, documentation is something that internal IT departments are usually a little light on.  It can happen for a lot of reasons, even when I worked for corporations in internal IT, my documentation was no where near as good as I feel it is now.  In a small IT department it can feel like you are just writing the documentation for yourself, like no one is going to look at it anyway. As an IT consultant however, your documentation is like your business card! The customer is going to look at it at least once J and it is nice when it is thorough and easy to understand.  Additionally, if another engineer has to work in the environment, you get to share the documentation with them and bask in their awe of your skills haha.  Really though, everyone tries to up their game with documentation at LookingPoint and word of a new diagram spreads “did you see Chris’ SD-WAN diagram?” “Which icon set did he use? those look great!” from engineer to engineer as we all look to improve. That same attitude can happen internally, but it is a constant moving target. Documentation has to be built in to the process and just a part of completion. 

IT infrastructure’s purpose is to enable the business and this is best done with devices that are configured, managed and maintained in a clean and consistent way following best practices that have been refined through experience and then documented clearly and thoroughly. At LookingPoint Managed Services we enjoy working closely with your existing IT staff and we don’t hold back the ‘secret sauce’…we don’t believe in holding on to knowledge to increase our value to you. Our value is in our sharing of the knowledge.

Written By: Lee Jolly, LookingPoint, Inc. Systems Engineer VCP CCNP