← Back to Nexus

Nexus — I&O Change Inventory Spec

From meeting with IT Operations management. Scope: Configuration Management, Web Administration, and Database teams first.

Goal

Build a structured inventory of I&O maintenance change types. For each type, capture:

  1. Who needs to be involved (stakeholders within I&O)
  2. How they're notified (communication mechanism)
  3. What must be validated (health checks, tests)
  4. When the change is allowed (approved change window)

The output is a CAB-ready plan — something that stands up to CAB questions without gaps. Using this framework is a prerequisite to going to CAB.

Scope: Initial Teams

Role Domain
IT Operations Manager Oversight across all three teams
Configuration Manager CMDB accuracy, asset records
Web Administrator Web-facing applications, endpoints
DBA Lead Database servers, schema, data integrity

Start here. Expand to broader I&O (Network, Security, ESS) after the framework works for this group.

Change Types (10–15 to start)

Examples from the meeting:

Change Type Notes
Database patching Which databases, normal maintenance window (varies by database), validation strategy
Database kernel tuning
(~13 more) To be identified with the team

For each type, we need:

The Validation Problem

This is the hardest part and the most important feature.

Current state: Knowledge is tribal. People know the right checks for each piece, but there's no library.

System Category Validation Method Coverage
Core enterprise platform Automated testing suite Core paths only, not edge cases
Claims processing systems Manual Run test transactions through the systems
Web content platform Manual
Commercial off-the-shelf apps (database-backed) Manual
Other applications/services Varies Different health checks per application

The gap: Every application and service has a different type of health check. If someone touches one system, there are steps not covered by the standard workflow. There's no "if you touch X, run these validations" library.

Goal: A validation mechanism that maps change types and affected systems to the right health checks. Captures tribal knowledge into something repeatable.

The User Flow

Checklist-driven. Not a form — a series of decisions or questions:

  1. What type of change is this?
  2. What systems are affected?
  3. → For each: have you done this? (validation checklist)
  4. Who needs to be involved?
  5. How are they being notified?
  6. Is the change window appropriate for this type?

The result: a plan that feels solid. Something better than what the team would have produced without it.

What "CAB-Ready" Means

The plan should answer CAB questions before they're asked:

Privacy Note

This tool is hosted externally. It does not and should not capture:

All data captured is at the team, role, and change-type level only.

Open Questions