IT Manager's Handbook: Getting Your New Job Done (47 page)

Define Your Scope

In order to avoid being overwhelmed with information, you should start at the highest levels and work your way down to the detail you think you'll need. The level of detail you need as a manager varies and generally depends on the size of your organization and the size of your staff. As a manager, you probably don't need to be tracking nitty-gritty inventory details like serial numbers, firmware versions, room and rack locations, etc.—but you want to make sure that someone on your staff is doing that.

An excellent way to determine the scope of your inventory is to think about a disaster recovery scenario in which you have to bring the entire IT infrastructure up after a major failure (such as a fire, earthquake, or hurricane). If you can walk your way through the entire recovery scenario, then your scope is complete. If you find yourself guessing at some of the elements of your IT infrastructure, then your scope needs refinement.

In this situation, a picture can be worth a 1,000 words. Very often the easiest way to get a clear view of an environment is with a schematic diagram. Not only do they convey a great deal of information, but your technical staff will probably find a diagram easier to create (and maintain) than the equivalent material in text.

The Elements

Wide Area Network
(
WAN
) Environment

A typical WAN schematic (see
Figure 7.1
) includes site locations, types of connections (VPN, leased-line, MPLS, frame relay, Internet), backup communication facilities, carriers, bandwidth, firewalls,
DMZ
s, etc. You may also want to include types and number of servers, number of users, IP addressing, key contacts, and street addresses. In many cases, you may have connections to third parties such as service providers (e.g., payroll) or partners (e.g., suppliers or distributors). Not only do you want to make note of the connections, but you probably want to indicate who is primarily responsible for the connections and the hardware: sometimes you are, sometimes the third party is.

Figure 7.1 
Example of a WAN schematic.

The WAN schematic should be updated regularly and distributed to members of the IT department. It should be posted on the wall of the data center for easy reference. The network manager should have it posted by his desk. It takes work to create one of these, and more work to keep it current. But it is an invaluable aid to the entire department. If you do not have one, go make one. Many network management tools have features to help you generate a WAN diagram.

Local Area Network
(
LAN
) Environment

The LAN schematic is the next level of detail. A typical LAN schematic (
Figure 7.2
) drills down into some of the detail of a particular site. It should include the topology, location, and connectivity of switches, and routers. It should identify different types of cabling (copper, fiber). It can also include room locations for various network equipment, model numbers for key components, IP addresses, wireless capabilities and so on. Like the WAN schematic, the LAN schematic should be regularly updated so that it is always current, and distributed widely so it is available for easy reference to all who need it.

Figure 7.2 
Example of a LAN schematic.

If your responsibility includes the phone system, it may also be appropriate to include information about the voice environment on the LAN schematic, especially if you're using VOIP. This data will include information about the switch, the voice-mail environment, trunks, and so on.

Carrier Connections

The carrier connections inventory goes into the details of the WAN connections that were defined in the WAN and LAN schematics. Items to track here include circuit numbers, circuit endpoints (including building and room numbers), carriers, type/speed of line (T-1, analog, ISDN, etc.), and phone numbers for reporting problems. Although telecommunications in the United States is very reliable, problems still come up. When a line goes down, you don't want to find yourself asking, “Which line?” and scrambling to find the circuit number or who you have to call to report the problem.

In larger environments, there are so many lines and so much activity with regards to adding, changing, and canceling them, it is quite easy to lose track. It is not unheard of for large IT environments to discover that they've been paying the bill on a line that they didn't know they had, and had stopped using years ago.

Server and Storage Environment

The documentation for the server environment drills down further and starts to give insight into how the applications work. In many cases, you may not be able to get all the detail you need into a single diagram. For example, you may find that you need one diagram just to indicate the basics, and others to talk about how key architectures (e-mail, active directory, storage area networks, etc.) are set up (e.g., indications of flow of data, like inbound and outbound mail, or servers that are operating in a cluster, etc.).

The documentation should also include which servers have Virtual Machine (VM) environments and some information about them. Of course, since VMs can be created, moved, and removed so easily, the value of detailed documentation for them could be short-lived, and it may be better to just refer to the information available from the VM management tools.

Mobile Equipment

Because mobile devices are so frequently purchased, lost, stolen, and replaced, this is a challenging list to compile and keep current if ever there was one—challenging, but important. The replacement costs in dollars aren't always high, but the security and manpower costs can be large. Spend some time now to save yourself a lot of heartache later.

Sample items to track include:

•
Cell phones (company-owned ones only—you'll raise eyebrows by asking about personal ones)

•
Netbooks, laptops, etc.

•
Tablets

Information here should include carrier, model, OS, and so on. Tracking mobile devices can be very difficult. Some of the carriers and vendors have reports and tools to help, and some third-party vendors are also starting to provide offerings. Some mobile devices now come with (or you can easily install) tracking capabilities.

Workstations

Keeping track of workstations can be an enormous headache because there are so many of them and there is a lot of activity with regards to refreshing, upgrading, and physical movement. As a manager, you should really be keeping track of only summary information (and leaving the details of the inventory to your staff and automated tools). Important summary information can include:

•
Device make and model

•
OS platform and version (Mac, Windows, Unix)

•
Date acquired

•
Configuration (processor, RAM, disk space)

You may also want this information broken down by department or location.

An often-forgotten portion of the total number of workstations are the ones that are remote: users who travel, users who have company equipment at home, etc. These often fall into the out-of-sight, out-of-mind category. It is important that these devices be treated like any other company workstation so that they can be tracked, maintained, and updated properly. And when an employee leaves the company, you can expect HR to ask IT if that employee has any computer equipment at home. Some
asset management
tools can track when a device last connected to the network. If a device hasn't connected in an extended period of time, it can mean the device has been lost or stolen, or perhaps just isn't in use and can be repurposed for use elsewhere in the organization.

Application and Software Inventory

We've suggested diagrams for getting an understanding of some of the components of the infrastructure environment. For the applications, it may be best to resort to a good old-fashioned list (although for complex applications with lots of data flowing in and out, a diagram can be very helpful).

When thinking of applications, we generally think of the big business applications (such as supply chain, HRIS, payroll, accounting, e-mail, etc.) But as long as you're developing an inventory, you should also include all the tools in use—application development tools, desktop tools (e.g., word processing, Internet browsers, etc.), infrastructure tools (e.g., backup and monitoring, etc.).

An application inventory can include items such as:

•
Application name

•
Brief description

•
User community (departments, number of users)

•
Current version number

•
Vendor

•
Number of licenses purchased

•
Terms of support and maintenance agreement

•
Database environment

•
OS environment

•
Integration to other applications

•
Support/maintenance arrangements in place (and expiration)

•
Whether the application is considered critical

•
What server(s) the application runs on

•
What IT team is responsible for support

•
Where to find a copy of the current version

•
Installation information

•
Special considerations

•
Special backup requirements

•
Peak periods of use

•
Executive usage

•
Who needs to be notified when scheduling downtime, or when there's an unexpected outage

Vendors

you're going to deal with lots of vendors, and each will have several contacts for sales, billing, technical support, and so on. It's important to keep track of who you're dealing with and any special arrangements you have. Some vendors you'll call so often that you'll be exchanging stories about vacations. For others, like vendors of legacy environments that you speak with only once a year or so, this inventory will be very helpful.

This vendor inventory should also include information about your support arrangements with the vendor. When there's a problem you should know immediately where to turn to find out how to call for service, including phone number and account number, and what levels of coverage you're entitled to, when your support contract expires, etc.

It is particularly important that the information be current and available to all who need it. You don't want to wait until there's a component failure to learn that the support provider's phone number changed, or that your contract expired.

Tools for Tracking the Technical Environment

There are a variety of tools out there that can you help you (and your team) track what's in your environment. Hardware vendors in particular have tools available to help you track and manage their devices. In some cases, the tools will also integrate with other vendors’ products. Some tools can track and inventory, some can do management and alerting, others will do configuration management.

Many software vendors market management tools to integrate with products from a broad spectrum of hardware vendors:

•
Cisco

•
Hewlett-Packard

•
Dell

•
IBM

•
Symantec

•
Microsoft

•
LANDesk