Seven Best Practices Of Network Configuration Management?

Do you have integrity in the moment of decision when it comes to Configuration Management?  This is an issue that I think all Information Professionals need to have thought through before the moment of weakness, stress, and decision comes upon them in a network crisis. 

A properly designed Enterprise Networking environment is built from the ground up using a very formal architectural plan.  This architecture should have been carefully specified and approved by all decision-makers prior to the original deployment.  It should include everything from what devices are permitted on the network, what networking equipment is required, what protocols are to be used, how the administrator actions are conducted, and what operating modes of all of these components are permissible.  This formal process should have resulted in a agreed upon operating configuration for your network.  The standard enforced should be that no deviations are permissible.  The act of maintaining this lineup is called configuration management.

The challenge always comes when something goes wrong.  Problems normally include hardware failure, approved device unavailability, specific administrator unavailability, and glitches encountered during maintenance or upgrade of hardware or software.  Here the demand from leadership to "get the system up" to enable business to be transacted can drive intentional or unintentional deviations from the architectural model.  The question is how do you and your organization handle these cases?

Honestly, ask yourself how your team would or has acted in the following common situations. 

• A server crashes and no approved replacement server is available?
• The boss’ runs over his Blackberry with his car, but the only replacement that the cell company has is a newer model.
• A new "must have" upgrade to a piece of software ends up requiring the upgrade of a third-party utility or software service.
• A fiber media convertor dies, none are available to replace it, but a Cat-5e cable will do the job.

I think that the security, performance, and unintended consequence threats associated with operating the network in a previously unconsidered configuration are obvious.  Everyone knows that it must be avoided, but how do you perform the risk assessment that would be required to restore in a non-standard line-up.  Specifically, whose permission is required to do this?  How long can you do it for without elevating the decision?  Who needs to be informed of the deviation.

Here are some best practices for handling the crisis configuration management challenge.  The best of breed Information Professionals have previously thought these issues out before they need them:

1. Your configuration management plan should be written down so that you have a place to start.  All of the following issues should be included in its contingencies section.
2. Approval for change needs to be formally obtained, documented, and resolved after the
   configuration is restored.  You want a record of what took place and why.
3. You need a method for documentation the exact technical changes that occurred.  This can be useful for secondary troubleshooting, fault isolation, and even future permanent configuration changes.
4. You need to have a formal process for managing departures from not just approved components but from the specification that they were based on.  If you need fiber in the application, but only have copper, it could be a critical security decision.
5. There needs to be a way to determine who can approve not just unapproved, but deviations from specifications.  Is it the same or different from just topology decisions?
6. You must have previously decided if length of network non-availability is a factor in any of your decision-making.  How long will it take to fix? Are the rules the same on Sunday afternoon as on Monday morning?
7. A frequently unconsidered problem is finding that your aged contingency plans and equipment are not compliant with your newer service architecture.  Is that important? Is your Continuity of Operations (COOP) plan itself compliant with your CM?

Again, there are many more factors to consider, but if configuration management for an approved system architecture is important enough to consider on the front end, it must be a key consideration when an unexpected disruption is encountered.  If you don’t think through the possibilities before the crisis hit, your risk assessment under stress might not result in a tolerable resolution.

What do you think?  How important is configuration management and architectural integrity to you and your organization?  Happy Thinking…

That is my Information Technology Thought of the Day (ITTOD) for April 28, 2009 ©Scott Coughlin.

Related posts:

1. Security Through Obscurity vs. Configuration Management One of the bedrock principles of the information technology (IT)...
2. Network Design: Conformance vs. Customization Whenever you approach a new computer network project where you...
3. Ten Best Practices for Happy Computer Networks Here are ten things that every information professional should ensure...
4. The Best Enterprise Operating System This will be my first post in a series discussing...
5. Network Architectures: Are You An Outtie or An Innie? Today, I was involved in a meeting that was developing...

Related posts brought to you by Yet Another Related Posts Plugin.