Home‎ > ‎Technology‎ > ‎

CITI (Inventory)

Corporate IT Inventory

PLEASE NOTE:  This project is considered pre-alpha stage!   Right now the only code to download is a Catalyst based app that will be framework for the inventory project.  The next step will be to add the inventory plugin, I'll post updates here as that time draws near.


To create a flexible tool that will correlate, organize and leverage existing corporate data in a cost effective manner with minimal impact to users.


The intent is to create an information management framework that will leverage existing data repositories across the enterprise, rather than attempting to replace them or allow them to remain isolated data silos.  In addition, there are incredible advantages in correlating the data and presenting it through a common interface.

The Challenge: 

In my experience, IT departments tend to be a bit short staffed and overworked. There is little time to record all of the changes that take place, and often times updates are overlooked completely. For example, deploying a new Linux server may require updates to inventory, DNS, the ticketing system, network diagrams, monitoring system(s), cabinet diagrams, and more. The finance department may want to know about the details of the purchase, and what client(s) it is in support of. The backup and recovery team will certainly want to know details about the server – IP address, file systems and applications to back up. Whoever is responsible for the maintenance/service contracts will of course want to know where the new server is and what level of support to put it under. And the admins, what of the administrators? Won’t they want to know the IP address, how it is configured, how much RAM is in it, what the serial number is (to make support calls), the hostname, which switch/port is it wired to? What version of Operating System is on it? Has it been patched yet? How about if that system goes down (God forbid!) in the middle of the night? How long will it take to identify the impact to clients and pull up the contact information for the project managers? 

There are numerous systems available to manage this sort of information. More often than not, companies already own one or more of these systems. They may have several different monitoring platforms. They may have a client database, a ticketing system, even an inventory. The vision for this particular asset management framework is not to replace those systems, but rather work with them. Our goal is to work harder for the admin, so they don’t have to! I want to create a system that can answer all of their questions and give them all the data that they require to be effective in their jobs – all at their fingertips.

Specific challenges:

  • Data separation – Data is generally stored in a number of disparate systems, few of which are built to readily interact with other systems. Where possible, all data should be presented in a single user interface. Optimally, the users will be able to modify data from this same interface. Barring that, the interface should have links or pointers to easily access the applications’ native interfaces. In all cases, automated methods of tracking updates and keeping data synchronized should be implemented. 

  • Existing tools – Most likely the tools already in place offer the best price/feature ratio available to the company and it is not logical to try to replace these applications. It makes far more business sense to capitalize on the investment and data already collected. The old adage of ‘not reinventing the wheel’ is highly applicable here! 

  • User adoption – Users need to feel comfortable and confident using new tools. The new tools need to be intuitive and optimally, very similar in use/function to the existing tools. For example: if a particular department has historically used spreadsheets, this new framework should permit that familiar workflow to continue. Perhaps a macro embedded in the spreadsheet could update the new database automatically. Or the system might have an AJAX powered web page that replicates the spreadsheet. 

  • Different Views – individuals and departments throughout the enterprise naturally have different viewpoints and interests. This system should allow for that, delivering a perspective that is most pertinent to the user viewing it. For example, hardware statistics and information is most valuable to a system administrator, but a network engineer will be more interested in the connectivity of the same systems. A manager will probably want to be presented with statistics such as uptime, contract expiration, and similar data points. Finance department employees will naturally want to be presented with asset value and length of service statistics. Application engineers will primarily be concerned with the software associated with each system and sales persons will want to know what clients are impacted by these same systems. 

  • Data accessibility – with data stored in separate systems, it can be difficult if not impossible to mine for relevance. It would be challenging to know what all of the various software systems are and how to access them, let alone how to effectively use each.

  • Data integrity – Unfortunately, once a system appears to be out of date, ALL data stored within becomes suspect. For example, if a particular Unix server has been upgraded and the associated serial number was not modified, how can a user be confident that the rest of the data, much less the rest of the systems, is correct?

The solution: 

Sounds a bit lofty, eh? Perhaps so. In its infancy, I am striving to create a proof of concept and test the theory. I have had a functional inventory system written in Perl (using the powerful Catalyst framework). I am now building the interfaces to various other systems such as DNS (PowerDNS), Active Directory (authentication, points of contact, etc), Nagios, and RT (Request Tracker)

Update:  I still have that proof of concept running on a server, but I have essentially scrapped it and started fresh, this time building it with the idea of making it much more flexible (read: not specific to my environment!).  My intent is to build this in a manner that will allow me to post the code every so often, hoping it will be generic enough that it will take minimal effort for someone to adapt it to their own environment.  As a first step, I have set it up to work with multiple forms of authentication, and have started building everything as plugins or modules.

Updates and News:

I am updating the documents on a semi-regular basis here, but the short news clips I'm leaving on Sourceforge:  https://sourceforge.net/projects/citi/develop

This is also where I am hosting the code at, both in tar format and SVN.