01 · Survey
Find out what's alive before you specify any of it.
An estate holds more than anyone remembers, and much of it no longer runs. The survey produces an inventory, usage evidence and one recorded decision about the fate of each capability.
Inventory
A library tells you what exists. Usage tells you what's alive.
Start with what the machine records rather than what people recall, and read it across a full business cycle. A program that looks dead in June may be the one that closes the year.
Name each capability in business terms. "Late payment follow-up" can outlive any system, but "ACLP210" can't.
| Evidence | z/OS | IBM i |
|---|---|---|
| What ran | SMF, scheduler history | QHST, job logs |
| Who touched what | RACF and SMF audit records | QAUDJRN |
| What's scheduled | Enterprise scheduler | WRKJOBSCDE |
| Who read the output | JES spool, report archive | Spooled files, output queues |
| Who called what | CICS statistics, MQ statistics | Journals, exit programs |
Disposition
Four possible fates. Every capability gets exactly one.
Move
Workflow, intake, review and human decisions. This is the Standard's home ground: it gets specs and an application.
Retain
It stays, and an automation Lambda hands work to it. The usual fate of ledgers and balances.
Replace
A commodity need that a product handles better. It still gets rules, which become the product's acceptance test.
Retire
Nobody needs it. State who was asked and what evidence shows it's safe to stop.
At Tidewater
| Capability | Today | Fate | Reason |
|---|---|---|---|
| Ledger and balances | Anchor Core | Retain | Ledger-class data, which the Standard doesn't hold |
| Late payment follow-up | ACLP210 nightly | Move | Workflow, and the Standard's Payments application specifies it |
| Remittance intake | TWRMT100, Connect:Direct | Move | File-driven workflow |
| Funding notices | MQ into Anchor Core | Move | Part of reconciliation |
| Payment correction | CICS TWPY | Move | A human review belongs in a process |
| Payoff quotes | BankLink | Move | A front-door request that reads a balance from Anchor Core |
| Insurance tracking | KeelTrack on IBM i | Replace | A commodity service |
| Monthly statements | TWSTMT | Move, once a balance extract exists | True bulk work. Statements show balances, which stay on Anchor Core |
| Past-due print report | TWRPT44 | Retire | Spool entries purged unread for 30 months |
Records and ledgers
Three questions decide what can move.
The Standard can become the only source for a record once a system retires. It doesn't hold ledgers. Data is ledger-class if any answer below is yes, and everything else is an authoritative record that its business owner and data steward can decide to move.
- Does its value accumulate from many postings, rather than being recorded as a fact?
- Must someone outside the team reconstruct it as of a past date, including corrections recorded later?
- Can a wrong value only be caught by reconciling against an independent control total?
| Tidewater data | Class | Lives in |
|---|---|---|
| Loan identity, terms and status | Record | The Standard, as it already says |
| Scheduled payment status, funding notices | Record | The Standard, once moved |
| Late fee calculation | Record | Payments calculates it and hands it to Anchor Core |
| Current balance | Ledger | Anchor Core; Loan holds only "as last reported" |
| Accrued interest, general ledger | Ledger | Anchor Core |
What this means for switching off
Tidewater can move its workflow, but Anchor Core stays on until its ledger has a home. Be honest about this early, because the savings from turning off the machine wait for that second project.
What surveys miss
The estate is bigger than its programs.
These rarely make the architecture diagram, and they often hold the rules nobody can explain. Tidewater's examples show why each one is worth a row in the inventory.
Ask what someone does after reading it. TWRPT44 went unread, so it retires. Sam Whitfield acts on TWRPT09 every month, so it becomes the exception review task and the report itself goes away. The quarterly regulator summary TWRPT61 really is a report. The method doesn't prescribe where it goes, so that's Tidewater's choice: a scheduled process loads its reporting system, and the summary is built there. A monthly PDF statement is simpler still: custom code that a process runs.
TWCODES, a shared VSAM table, holds each bank's grace days under keys such as GRACE0417. These become the tenant parameter grace days. Of its other 212 codes, usage evidence shows 38 are read. Those become choices or parameters, and the rest are dropped with a reason.
A sort card can hold a business rule, as ACLP210's does. An IDCAMS REPRO backup step doesn't. Read every one, then record which it was.
Business calendars, period-ends and holiday files change what programs do. Tidewater's bank calendar was found only in the parallel run.
Operators' restart notes, a spreadsheet kept beside a report, a phone call to a bank at month-end. Sit with the people who do the work. Interviews count as evidence, labeled as interviews.
Rules
MIG-001 to MIG-004, MIG-046
- MIG-001
Every production artifact in scope appears in the inventory with a named owner, or with "no owner" stated.
- MIG-002
Whether something is alive is decided by usage evidence covering a full business cycle, not by its presence in a library.
- MIG-003
Every capability has exactly one recorded disposition: move, retain, replace, or retire.
- MIG-004
Ledger-class data stays off the Standard, so it is retained or replaced; any other data becomes authoritative there only by the recorded decision of its business owner and data steward.
- MIG-046
Each report that survives has its route recorded, and the method prescribes no reporting product.
# Survey sheet — <capability> - **Capability:** <what the business needs done, without naming a system> - **Business owner:** <one person, or "no owner"> - **Technical owner:** <one person, or "no owner"> - **Platform:** z/OS | IBM i | other ## Artifacts | Artifact | Kind | Library or location | Last changed | |---|---|---|---| | <name> | program, copybook, job, sort card, queue, table, grant, screen, report | <where> | YYYY-MM-DD | ## Usage evidence (MIG-002) - **Window covered:** YYYY-MM-DD to YYYY-MM-DD, including <period-ends> - **Source:** SMF | scheduler history | QHST | QAUDJRN | job logs | spool | <other> - **What it shows:** <runs, readers, last used> ## Disposition (MIG-003) - [ ] Move — to application <name> - [ ] Retain — postings handled by process <name> (MIG-040) - [ ] Replace — with <product>; rules become its acceptance test (MIG-017) - [ ] Retire — nobody is harmed because <reason> - **Ledger-class data?** (accumulates from postings; reconstructed as of a past date with later corrections; checked only by independent control totals) no | yes → retain or replace (MIG-004) - **Records' past (MIG-045):** transferred record | history kept, because <future need>, with <what it depends on> - **Becomes an authoritative record?** no | yes → decided by <business owner> and <data steward> - **Decided by:** <who> — YYYY-MM-DD - **Reason:** <one sentence>