When I was a kid, my brother Mike and I were playing Cowboys and Indians one day. Another kid shot brother Mike, who went down with a convincing death scene.

So convincing that Mr. Peepers, our loyal half sheep dog and half lots of other breeds sank his teeth into the shooter’s ankle.

Mr. Peepers understood something profound. It starts here: We knew who the good and bad guys were without having ever once met either a cowboy or a Native American, just as when we played Cops and Robbers.

Mr. Peepers understood who the good and bad guys were, too, only his perspective had nothing to do with cowboys, Indians, cops, or robbers.

Happily, brother Mike’s killer didn’t end up with rabies, nor did any of us end up infected with animosity toward Native Americans, or, for that matter, toward robbers. But playing Cowboys and Indians probably did give each of us a bit of a cognitive hill to climb when the ’60s came along and exposed us to, in addition to the occasional doobie, a less one-sided view of who did what to whom in American history.

Back to Mr. Peepers.

As has been pointed out in this space from time to time, most of us, most of the time, divide the world into us and them. We are the source of all that’s good and right with the world, they cause everything and anything we dislike. That’s true whether we consider “us” (or them) to be: Democrats, Republicans, Unix jockeys, mainframe dinosaurs, scientists and engineers, pointy-haired bosses, whistleblowers, loyalists, mavericks, bureaucrats, ELCA Lutherans, Missouri Synod Lutherans, or …

You get the picture. Now paste in Mr. Peepers. As the rest of us divided into two tribes — cowboys and Indians — Mr. Peepers knew which tribe he belonged to, and it was neither of the above.

He was a Lewis.

We’ve talked about culture from time to time in this space, defining culture as how we do things around here.

Or perhaps it should be how WE do things around here, because how, and for that matter what we do around here is dictated by relentlessly enforcing peer pressure. Every affinity group has its own approved narratives, which means all of us … not most of us, all of us … are subject to starting our thinking about whatever issue floats into our view by matching it to one of these approved narratives.

The narrative supplies the logic. Evidence? We might find it interesting, but mostly to the extent it provides ammunition, not illumination.

Our thinking works this way whether we’re evaluating our employer’s decision to lay off staff due to COVID-19-driven revenue shortfalls or we’re deciding whether to wear face masks in public places.

And while there’s a glimmer of hope for developing a COVID-19 vaccine, there’s no such outlook for immunizing us from tribal thinking.

The best I can do is offer a palliative: Whatever the controversy at hand, join a non-combatant tribe and follow its narratives. Ideally it would be a tribe that has a legitimate stake in the subject and isn’t one of the major current combatants.

When I find myself falling into a tribal trap my go-to is trying to climb out of it by self-identifying with the tribe of engineers, where I define “engineer” as someone who, faced with a problem, sees it as something to solve, as opposed to non-engineers, who respond to problems with “Oh, no!”

But it depends on the situation: If the question at hand is, for example, the aforementioned round of layoffs I might instead choose the tribe of Bloomberg opinion-writer, where I’d be deeply interested — it is, after all, my beat — but not predisposed to a particular opinion as to whether any specific layoff decision is a good or bad idea.

The great thing about conscious tribal choice (should we make this an acronym? CTC?) is that we don’t have to pass any tests or otherwise get anyone’s approval to join.

In fact, this would defeat the whole purpose, which is to drain as much hero/villain thinking from our brains as possible.

Maybe we should all make one of our alternatives the canine clan.

Because I don’t remember whether Mike was a cowboy or Indian on that fated day, so I don’t know if his killer was a hero or a villain. Mr. Peepers, on the other paw, knew the killer wasn’t a Lewis.

That’s all he needed to know.

There are, according to the KJR Manifesto, no best practices, only practices that fit best.

More often than not, though, “best practice” refers to neither. Most so-called best practices are really no more than minimum standards of basic professionalism.

Take a situation I’ve run into several times over the past few years: Whether due to mergers, acquisitions, and divestitures, years of IT being stretched too tight, or just plain sloppy management, IT can’t produce an accurate business applications inventory.

Clearly these IT organizations aren’t in sync with “best practices,” which call for instituting:

  • PMO (Program Management Office): The body responsible for reviewing, approving, and tracking all IT-related projects. The PMO matters because it’s the projects it oversees that change the applications inventory.
  • CMDB (Configuration Management Database): A repository that keeps track of What’s Installed Where. Business applications are among the “configuration items” the CMDB keeps track of, along with every piece of real and virtual hardware, server OS instances, DBMS instances, development environments … every item IT has to keep up and running.
  • CAB (Change Advisory Board): The organization responsible for reviewing all “change requests” (read “installation requests”) to make sure development teams, IT infrastructure teams, and anyone else trying to change the IT production environment has dotted all requisite i’s and crossed all corresponding t’s. Also, for making sure someone updates the CMDB to reflect every change.
  • EAMS (Enterprise Architecture Management System): An information system that keeps track of … well, of all layers of the enterprise architecture, from hardware at the bottom to platforms layered on it, to information repositories, applications, and the business capabilities, functions, and processes that depend on them.
  • ARB (Architecture Review Board): Enterprise Architecture’s enforcement arm — the organization that reviews all IT-related plans to ensure they conform to the company’s technical standards. And, for making sure every change results in an update to the EAMS.
  • Forms: Lots of forms, to make sure each change consistently updates the CMDB, EAMS, and enterprise project portfolio to keep them consistent with one another. Or, as an alternative, application integration that makes sure an update to any of these systems synchronizes the others.
  • MA (Mandatory Arbitration): With three different committees, each responsible for finding flaws in the creative work of other people, do you think all parties will agree? Envision the oarsmen on a trireme with multiple captains directing them to row in different directions.

Forget (or at least delay) best practice. Achieving the minimum standard of basic professionalism in all this is more than ambitious enough. And that’s having a single, trustworthy application inventory. What it will take:

Count each application once. Is the application installed on multiple servers in multiple locations? Doesn’t matter. Count it once. Do you have separate Dev, Test, Prod, and possibly other intermediate instances? Doesn’t matter. Count it once.

Do you have multiple versions or releases installed? That does matter — count each of these as separate inventory entries.

Determine application granularity. If you, like most businesses, rely on large-scale suites to support major business domains (e.g. Workday for HR, Salesforce for CRM, SAP for ERP), the suites aren’t granular enough. Make each module an entry.

If your business is at the other granularity extreme, microservices are too granular to track in the inventory. Go up a level and track the applications microservices assemble into.

Manage app/platform dualities. To take an example, SharePoint is both an application and a platform for building applications. Track these uses separately.

Track the bare minimum. For each application track its name, version, product owner (or non-Agile equivalent), IT support lead, a brief description, and vendor. If you can’t easily implement the inventory on a spreadsheet you’re being too ambitious.

Related: If you find yourself tossing around terms like “metadata,” stop unless you’re planning on using an EAMS for the job. Don’t even daydream about metadata until you have an accurate inventory.

Survey the business. Ask each top-level executive this question: “What are the five applications your organization relies on the most? Please reply; also please forward this survey to your direct reports, asking them to respond and also to forward it to their direct reports.”

Use the results to validate your inventory, but be careful. Your business respondents might not use the same application names you used in your list.

Enlist the PMO and ARB. Ask them to let you know of any new applications being installed, updates to existing ones, and retirements.

And finally, instill in everyone the first rule of inventory management: What the inventory shows today will be wrong by this time tomorrow.