Mythology, Reptiles, and Whiskey: Their Effects On ICT Lifecycle Management

"Can you remind me - what's the name of the new project you're working on?"

"It's called Apollo". Hmm - what you mean it based on the new Apollo servers we bought? Or is it a server called Apollo? Or it is using software called Apollo? Or from the company called Apollo? Or its a collection of hardware and software all known internally as Apollo and delivering a new CRM capability? Or is it the project is called Apollo? Or is it serving the Apollo building on the campus?

Why is it so important what you call something? Look at the multitude of naming systems used by IT teams where a name can be very specific on role or function, or they can mean nothing at all - quite deliberately. It's useful to identify and name your main firewall as Main_DMZ_Firewall, but you could also use an asset number like N36636. Which is best if you want to stop hackers? If the firewall status goes red on a monitoring system, what would you want to see displayed - N36636 being down is less useful than Main_DMZ_Firewall. So equipment naming can create conflicts and lots of opinions as different IT teams want to know what it is, where it is located, what it does, what its part of, ownership, etc. And different levels of detail will apply as well.

Using the same name for any part of the IT infrastructure would help

Experienced IT professionals will apply a life cycle thought process - say a 20 year period and predict that you will end up with an evolved legacy environment which is difficult to understand and has multiple naming conventions. This is how Snakes, gods, drinks, cartoon characters, cars somehow end up on an IT asset list and on lots of cable labels. In the long term, best practice seems to be to have generic naming along technology boundaries, while a common identifier such as an asset number on a bar code is referenced to gain access to logical name, location, role, function, type, OS, IP address, owner, etc. We see the same method also applied to cable identifiers where a unique reference is simpler and re-usable, rather than labels with equipment and port names, roles, paths, types, etc. When server and network teams change their naming conventions, does anyone look forward to ripping off old labels and creating new ones on live, data critical connections? Plan ahead - simplify things so you remove effort and risk by life cycle thinking and altering existing practices (which many don't follow through on anyway).

Sounds simple? It should be. Naming conventions should work for a long time and be understood by the next generation of IT, or a short term contractor, or a new service provider. But... the infrastructure information needed by different teams for change and risk processes still needs to be available and maintained - in spreadsheets, databases, etc. along with supporting schematics that explain complex space, data or system complexities. At least they use the same names for the same devices - or maybe not.

Yes, the can of worms is now opening. If you change equipment names or connections it is not just the physical labelling that needs to be updated - what about the latest diagrams and design documents? Will they be updated also? The answer is often the same - what diagrams? It still seems to be a struggle to maintain any form of institutional documentation within teams, often left to team or individual direction and motivation.

The only solution is to look for simpler, easier ways that reduce the workload on teams who plan, manage and operate IT infrastructure. It needs IT management to decide where investing in process and method will reduce the workload on the limited IT resources they have to deliver services. It could be a mix of allocating time, bringing in external expertise and recognising where supporting toolsets and skills need to be enhanced. And using the same name for any part of the IT infrastructure would help...

Dave's Pet Peeves

Not much to say this month. Too tired from a data centre migration project where the end customer, their service provider and the contractor brought in to move the equipment all used different names to plan the moves. As the AssetGen system was used to document the inventory and connectivity we had to herd cats to settle on one naming system for racks, equipment and port types. After that was accomplished it was easy to create inventory lists, rack diagrams and connectivity diagrams in a few minutes. It was the 4 weeks explaining why consolidating spreadsheets into one database that was painful.

Maybe the next project will be simpler and the naming will be simple and consistent. Wishful thinking?

Visio Corner

Here is a video of our new Visio combo connector that shows how easy it is to display ports, cable ID, IP addresses and VLAN from embedded data. Now available on request using our web site contact form.

Upcoming Events - 2024

June 20th?? – ?Free Webinar, Automated Refreshing of Infrastructure Documentation Details & Registration

July 18th? – ?Free Webinar, Part 4 Industrial and IoT Diagramming Details & Registration

I hope you enjoyed this edition of this newsletter, make sure you subscribe by clicking the button at the top of the page to keep updated on future articles and events.