Boundary setting for merger application landscapes

Mergers compress years of independent application growth into a single governance forum. Each side arrives with diagrams that stop at their former organizational edge. Dependency analytics cannot start until someone names a perimeter that is small enough to finish and large enough to matter for the first joint release.

A perimeter that works in practice

Choose the customer journeys or regulatory processes that must run across both estates within twelve months. Include every application that participates in those journeys, plus shared identity, payments, and batch reconciliation services that touch them. Exclude “interesting but unrelated” systems even if executives want a complete census on day one.

Naming conflicts and duplicate masters

Expect two customer masters, two product codes, and three definitions of “active contract.” Record the duplicates as dependency risks with business owners, not as data-quality tickets for a future cleanse program. Architecture work during a merger earns its keep when it prevents a dual-write surprise in the first shared release train.

Network Architects treats merger assessments as time-boxed decision support. The goal is a shared map for the journeys that matter now — not a permanent encyclopedia of both former companies.