Seven Indicators of an Ineffective Network Design Activity

This is a follow-on to the post Well Executed Service Design Provides Substantial ROI.  The previous post discusses the rationale for investing in the service design activity.  This provides some indicators that the service design processes are ineffective in the context of ITSM best practices.  Take the quiz below and see how your organization scores:

How much of your network is in compliance with the standard design templates?

  1. Over 90%
  2. Between 50% and 90%
  3. Less than 50%
  4. We don’t have design standards
  5. What are design standards?

If you answered “E” just follow the “Contact Us” link at the bottom of the page; you’re in trouble. If you don’t have design standards then do likewise. If less than 95% of your network isn’t in compliance with established standards, then they aren’t standards – they’re suggestions. It’s very likely that you are provisioning devices without a detailed design. This is the most common indicator of an ineffective service design process.

How do you know if your devices are in compliance with standards?

  1. We provisioned them by design and don’t change them ad-hoc
  2. We use a configuration management system that validates compliance
  3. Spot check
  4. We don’t really know
  5. Answered D or E to the previous question

Ideally you should build and provision your network by design and not make changes to it that aren’t defined by subsequent releases of the design. There are many compliance validation systems on the market that do a great job of validating IOS compliance, configuration compliance against a template, and so on. While these tools have great value in an organization with a loose design program, they address the symptom rather than the problem.

How much effort does your engineering team expend resolving incidents?

  1. Engineering is rarely involved in operational issues
  2. 20% or less – only difficult issues Tier 3 can’t isolate
  3. Over 50%
  4. Engineering is Tier 3
  5. Don’t know

There is some merit to engineering working operational issues. It keeps the engineers sharp on troubleshooting skills and helps them understand the details of the incidents in the field. Often an engineer will identify a design fault easily and open a problem case. However, if the engineers can’t spend adequate time doing engineering because they’re troubleshooting operational issues, then something is terribly amiss. If the network is so complicated that Tier III can’t identify a problem, then engineering needs to develop better tools to identify those problems rapidly. If engineering is constantly needed to make changes to devices to resolve failures, then the network design is lacking. Engineering being involved in incident resolution is an indicator of a poor or ineffective network service design.

Who identifies network metrics and the means to collect them?

  1. Engineering
  2. Performance Management Team
  3. NOC
  4. Senior Management
  5. Don’t know

Did you have to install the speedometer, oil pressure gauge, etc. as aftermarket add-ons to your automobile? If you’re designing something, and there are performance criteria, the design needs to include a means to measure that performance to ensure the system meets the requirements. Your service design program should be developing metrics and alerts as an integral part of the design.

Does Tier III ever have to modify a device configuration to resolve an incident?

  1. Only in predefined circumstances, such as hot spares
  2. Sometimes
  3. Only in outages with very high impact
  4. Absolutely! That’s why it’s necessary for tier III to maintain level 15 privileges
  5. This question doesn’t make sense

The configuration of a device is part of the system/service design. Does the auto repair shop ever redesign your car in order to repair it? There are a few circumstances in a network system where config change may be a valid repair action. For example: Bouncing a port on a device requires the configuration to be changed momentarily, then changed back. Perhaps there are hot spare devices or interfaces that are configured but disabled, and the repair plan is to enable the secondary and disable the primary (this is actually part of the system design plan). Aside from these few exceptions any modification to a device configuration is a modification to the network design. If the design has a flaw, there should be a problem case opened, the root cause identified, and the fix rolled into the next release of the service design. When design change is a mechanism used to correct incidents, it indicates a lack of a cohesive design activity.

What does Release Management consist of?

  1. A scheduled update of the (network) service design with fixes and enhancements
  2. A schedule indicating when field devices will be modified
  3. Scheduled releases of IOS and network management software updates
  4. Patches to Windows desktops
  5. This concept doesn’t apply to networks

The design of the network must continually be improved to add new features, support additional IT services, improvements to existing aspects of the system, fixes to problems, etc. A best practice is to release these design changes on a scheduled cycle. Everything in ITIL is in the context of the “service”. In the case of network services this is the entire network viewed as a cohesive system. IOS updates, software updates to support systems, etc. are released by the manufacturer. Although these are part of the network system design, they do not constitute a release of the network service. For example: Network service version 2.2 may define JUNOS 10.4.x on all routers and version IOS 12.4.x on all switches. Release 2.3 of the network service may include a JUNOS update as well as an enhancement to the QOS design and a configuration modification to fix a routing anomaly discovered during the previous release. It is the service that is subject to release management. The updated service design is then provisioned on the applicable devices using a schedule that is dependent on multiple factors – mostly operational. The provisioning schedule is not the same as the release schedule. Release 2.3 may become approved on March 1 but not provisioned across the entire network until August through a series of change orders. A well established network service design program uses release management.

Is there a distinction between the design activity and the provisioning activity?

  1. Design is an engineering function, provisioning is an operational function
  2. The design activity involves a great deal of testing and predictive analysis
  3. Provisioning effects operations and subject to change management
  4. Provisioning is applying the standardized design to distinct devices and sub-systems
  5. All of the above

Network service design and provisioning are too often blurred or indistinguishable. A design is abstract and applies to no particular device, but contains enough detail to be provisioned on any particular device in a turn-key fashion. Most organizations design particular devices, thus skipping the design and incorporating it with provisioning. When this happens the design process must be repeated for each similar instance. Few CABs make the distinction between the two activities causing change management to become very labor intensive because the provisioning activity becomes subject to all the testing and scrutiny of the design activity and the design activity subject to all the operational concerns of provisioning. This is another indicator of a poorly functioning network service design activity. Note: This is the only question where “E” is the best answer.

 

Contact us if you’d like some help moving forward.

 

Contact Us Today