Architect and verify

A new system rarely stands alone. It needs data, a login or a function from a system that is already running; it needs ports opened between the two; and it needs software on a server before it can start. The deliverable here is one architecture document, proven row by row. It starts as to-be — what the design says — and ends as as-built — what was measured.

The failure this skill prevents is the architecture drawn from what people believe. An old diagram says a port is open. Someone remembers which SDK the server has. On go-live day one of those beliefs is wrong, the new system does not start, and nobody can say which belief it was. The cure is a mark on every fact, a test on every row, and each result written where its fact is.

The boundary comes first

Before anything else, settle who acts. You read and you test. You do not change either system. Every change — a firewall rule, an installation, an account — is made by a person: the user, or a colleague in another team. Do not do "just the easy half", and do not quietly widen your access to finish something. A boundary that you cross once stops being a boundary.