A Sysadmin's Perspective of IT Asset Management
Table of Contents
by:
Tuomas Haarala
My Motivation for IT Asset Management #
We’ve probably all heard the story about a group of blind men who try to describe an elephant. Each of them feels only one part of the elephant and so gets a very different idea of the animal to the others. As none of them are stomped to death, we can safely assume that the elephant is tame. This probably feels very distant from IT asset management, but it happens to be relevant. If you decide to skip managing your assets, you will eventually share the experience of the blind guy who couldn’t tell what elephants are like, but knows from personal experience what they leave behind. In reality, the exact number of devices in your environment is probably trivial to come up with. At least you can come up with a rough estimate and get more exact results after a while. If you think about it, addresses, locations and other characteristics seem essential in describing what you have.
My view on the subject of IT asset management comes from the world of system and network administration, on an infrastructure level. I like to think that having at least some level of understanding of IT asset management is good information for pretty much anyone involved, independent of their area of expertise. Managing assets might have the feel of making lists; boring, seemingly useless, and something for parchment-dry people with dust on their shoulders. Being far from that mental image, IT asset management is actually a multidimensional map of everything, spanning over several documentation systems, each of which provides a useful view to a specific audience. The subject I will not touch in this post is mapping the installed software on workstations. They are indeed software assets, but somewhat distant to the world of infrastructure and usually closer to authentication and workstation management solutions. Having an easily accessible set of asset information can be very convenient, helpful and even feel like a life preserver in times of crisis, no matter what your point of view happens to be.
When Minutes Matter – a View into the System Administration Job Description #
If you have experienced an emergency of any nature in your line of work, you know how difficult it is to get the required information right then and there. Minutes are running, systems are down and you really need to wrap your head around what has happened in order to get things under control. You may need to know which systems were in the location that a meteorite just wiped out. Or maybe you need to know which of the systems providing your customers with services have a vulnerable combination of software or hardware in them - or something entirely different. IT asset management as a concept is the way to provide you with that information.
Much of that information you have built into a mental map over the years and it won’t be your problem anymore if you happen to be in the service center that the meteorite hits. However, it might just as well be you who has to pick up the pieces and start figuring out where to go from there. Being able to pull address allocations, server locations and types, OS versions and being somewhat agile about it saves crucial minutes when a disaster hits. That is, if your asset management tools weren’t among the vaporized servers in the disaster. Planning for disasters, you likely have that covered.
Everyday Benefits of IT Asset Management #
We all value things that are neatly in order. Unlike me, some admins extend this practice to having their desks ordered in a specific way as well. Some call my desk chaotic, I like to think of it as a natural, chronological order of things. The benefit of having things in common with others in order is another thing. The physical aspects from hardware types, locations, cabling and such are essential for us techies. If you are about to drive several hours to a remote location, you really don’t want to have the wrong parts or cables with you. Having patch cables of the correct length is a luxury that makes you look professional, if anyone is looking. At least you know they are there and you did a good, tidy job.
Yes, those who see your handiwork do appreciate neat work when they see it or even talk about pretty cabling when they see any. Having to coordinate network addresses becomes a breeze if you have means to see:
- what you have
- what is already allocated
- what is free to use.
That knowledge is also tremendously helpful when cleaning up firewall rules or setting them up. Contrary to an all-too-common belief, DHCP is not a way to manage IP addresses. It’s just a practical method for address distribution, serving those devices that wish to be served. To work out address allocation, you will need to perform some internal coordination instead of relying on a technical mechanism to do it for you. Dynamic addresses are fine; it just doesn’t make sense to track that aspect of an asset too closely for such devices. Being able to find which address a device has right now or had three days ago is another thing and very useful as such.
The physical aspects of an IT asset are easy to come up with. Having the time dimension taken into account in the lifespan is something more complex. Things will get a little complicated when we realize that the lifespan of hardware and software (base OS, virtual machine) differ from one another. Keeping hardware separate from the operating system installation is a good practice. Having those bound in a single entity is more of an anomaly in today’s world.
The Two Dimensions of Managed Assets – Physical and Digital #
In any kind of organization running their own hardware, you will have to be able to track the lifecycle of pretty much anything that uses electricity. Aging hardware can and in the age of RoHS likely will develop some issues. The importance of retiring hardware in time shouldn’t be belittled; having and acting to a good estimate on technical lifespan can save you from a lot of trouble. Hardware failure is typically considered an anomaly and something that doesn’t belong to the characteristics of a device. With cloud-based services, this feels very distant as you will have very little choice of what hardware you’ll be running on.
When dealing with physical hardware, having the ability to log hardware failures is very helpful. Being able to cross-reference hardware failures over time with other assets can reveal problems that could be impossible to figure out otherwise. For example, electrical feed issues in specific racks can manifest themselves in higher failure rates of power supplies, mechanical vibrations can cause otherwise unexplained problems in rotating components and even in solder joints in the circuit boards or cable connections. The digital, or perhaps the more abstract layer of assets has grown in the last decades with cloud-based resources, and some assets can have a management system supplied by the provider, DNS domain name management being a good example of this. Some of these systems do have APIs or even good tools to interface with, some don’t.
Having the asset information in a single system will make your life easier, even if it means building complex automation to enrich the original data set. Keeping it simple and avoiding complex and fragile integration mechanisms may add some routine work, but does allow bigger changes with less work.
Everything has a Lifespan #
Hardware lifespan consists of more than just “plugged in” and “died of old age”.
Planned lifespan should include:
- ordering and receiving the system
- installation
- operation
- reaching end of life
- disposal
Throughout the lifespan, it is a good practice to keep a journal of observations by logging:
- the replaced parts
- their method of disposal
- the disposal of the device itself.
Depending on circumstances, this might even be a mandatory practice.
It is important to find a way to manage your assets in a way that serves you well, while enabling you to provide the required information to related business functions with minimal effort. It will be a much more pleasant experience than having to adopt something the other party came up with and having no concept of what you have to work with. The lifespan of operating systems and software products is a topic that has become more prominent in recent years, as long-standing software products have finally met their end of life. Taking this into account not only in asset management but also in communication with parties that you provide services for is important and can prevent the involved parties from embarrassing moments, such as a development tool becoming obsolete just before a product release.
Installations should have their end-of-life latest at the time when the product runs out of support. In practice, there are always some exceptions. As the safety of unsupported products is often questionable, you will have to find ways around it, where a run-of-the-mill (and sometimes only) solution is isolation. Isolating obsolete, unsupported software is not a working solution for services provided over the internet, but works for retaining support capability with otherwise obsolete design tools, when legacy support is needed. At least operating system installations should be considered as assets in their own right. Deciding what to do with software installations is a different story. At minimum, documenting the installation and configuration process for your environment is a good practice. If the software provides a service to the network, it is a good candidate to be documented as an asset, as well as tracked for version and patch history.
Automation naturally is a great way to document IT assets and tracking the proceedings along with the current state of affairs often comes with the deal, should you automate your administrative tasks. Before going forward, it’s good to remember that the lifespan of an asset rarely matches the fiscal deduction plan.
Supporting the Financial Administration #
Those who deal with money write books about money and make decisions about money.
The way people in finance think can seem very different to the way people in technology think. As finance people live in a world where they count numbers to keep the taxman happy and things predictable money-wise, they will likely end up asking odd questions about servers, such as:
- How many servers are there?
- How much does a server cost?
- Why does a server we bought cost this much?
In reality, we may have asserted that a server cost can be anything from almost zero to five or six figures. Herein lies the second argument for keeping the OS installations and hardware separate. You will likely end up in a situation where you have to cough up numbers that reveal how much work, on average, a server installation will take during its lifetime, or annually. The price of a server (operating system and software) is very hard to pinpoint. You can have an installation that has very little work and money invested in it, while still being an essential enabler for the environment generating revenue, and the little invested value has been deducted over the years making the installation virtually worthless and thus unimportant.
Planning Ahead #
Accounting, as well as management, typically is very keen on making predictions. Server purchases are obviously large expenses and, as such, very attractive to use as a tracking method (how many servers your department buys in a year). This actually means “how much money your department uses in purchases per year”. Servers are only a red herring in this; likely leading to a situation where you are asked to reduce the number of virtual servers run on an expensive and capable hardware in an attempt to reduce the operating costs. In imaginary money and values this makes sense, in real world money it does not. Make sure that these kinds of simplifications don’t lead to absurd situations like the one mentioned above. Since the amount of work is somewhat stable, purchases of licenses, hardware and software are done with real money and are obvious targets for tracking. Try keeping finance and management happy with those and avoid confusing them with excessive numbers of assets with varying lifespans, estimated costs and qualities.
Probably the most important thing here is communication. Find out the needs of your counterpart and plan so that you can conveniently extract the information to fulfill their needs and purposes and to keep them happy. There is also the scary potential for someone else coming up with a spreadsheet for managing the assets, enforced through company policy and determination of top management that this is the way the company does things. Lead the target and get ahead of the spreadsheet folks, unless their latest work was so good that they are going to replace Michelangelo’s work in the Sistine Chapel with that. In that rare case, they might have something to make you happy as well. It’s always better to choose your tools yourself than survive with the ones you were forced to use.
How Should I Go About It? #
In the second part of this duology that initially was supposed to be a single write-up, I will take a look at the practicalities of IT asset management and asset discovery.
Until then, watch your step if you are walking where elephants graze.
