I wrote my own initially for our team. I wrote it so any team could use it if they wanted but it is written from a Unix server perspective. With it being adopted more and more, I'm rewriting it in a few places to accommodate other teams (networking: we have devices not servers) and have incorporated a changelog management process and server creation process along with a few extra specialized bits for other team requirements (web site certificate management with notifications prior to expiration). It's automatically updated via script or snmp queries and has email query capabilities.
It's one of those things that get a bit out of hand I guess. "Hey, that looks pretty good, can we use it?" or folks who used to be on our team taking access to it to the new team.
Of course there's the problem of if I leave or die what happens to the data (it's not all that complicated but someone would have to take over) but there are other problems with commercial products; changing the way we do things and shoehorning it into the ideas from a commercial company, changing environments where the current software is a physical asset tracking product and doesn't work well when tracking virtual assets or is difficult to update (manual updates with no provision for automatically updating the data), or even that the software (Magic) is end of life and unsupported so we have to move to a new system (Remedy) and have to change all our processes yet again and reformat our data to fit into a new paradigm (ITIL).
The company has decided to make my database "official" (at least for now) and during the transition, everyone uses my software as a staging area and I create scripts to export it into a Remedy friendly format vs everyone's current method of storing information (spreadsheet, text files, Sharepoint, a mysql database on someone's computer under a desk, or nothing at all).
[John]
