Two companies are merging and need to consolidate their order-management processes within a year. How would you use the BDAT layers to scope and sequence the impact analysis, and when would a full top-to-bottom BDAT analysis of both companies be the wrong amount of rigor for this kind of change?

## Scoping the analysis, layer by layer A scoped BDAT impact analysis for a merger starts by pinning down the business layer precisely: which capabilities and processes are actually being merged (order capture, fulfillment, returns) versus which are staying separate, and what the target end state looks like — one shared order-management system, or two systems federated behind shared reporting. From there the analysis traces downward one layer at a time. 1. **At the data layer**, it identifies the entities those processes depend on — Order, Customer, Product, Inventory — and checks whether the two companies' definitions conflict: does one support partial shipments and the other doesn't, do they use incompatible product identifiers, do "Customer" records overlap for people who buy from both companies. 2. **At the application layer**, it identifies which systems currently implement each capability and data entity in each company, and evaluates which to keep, retire, or integrate. 3. **At the technology layer**, it checks what each application runs on and what constraints exist — vendor contracts that can't be terminated early, license caps that don't scale to combined volume, data-residency rules affecting where merged data may be hosted. ## Why the tracing is structured this way This kind of structured, layer-by-layer tracing exists to prevent the classic merger-integration failure of "big bang" surprises: teams that dive straight into merging applications or databases without first agreeing on business intent and data definitions routinely discover mid-project that the two companies mean different things by the same term, or that a system everyone assumed was purely local to order management is actually load-bearing for other parts of the business. BDAT gives a repeatable checklist — business, then data, then application, then technology — so that a hidden dependency doesn't get missed simply because nobody thought to look for it. ## Rigor versus speed The central trade-off is rigor versus speed. | Approach | What it buys, what it costs | |---|---| | A full enterprise-wide BDAT model of both companies, covering every capability, every data entity, every application, and every server | Would be thorough and would very likely surface every cross-domain dependency — but it would take far longer than a year-long merger timeline allows, and by the time it's finished, parts of it would already be stale. | | A domain-scoped analysis, limited to order management and its immediate dependencies | Is fast and directly actionable, but carries the risk of missing indirect coupling — a data entity or a piece of shared infrastructure that looks local to order management but is actually consumed elsewhere in the business. | The practical resolution is to start scoped and treat the scope boundary as provisional: any time analysis surfaces a dependency reaching outside the initial boundary, that's a trigger to expand scope for that specific thread, rather than either ignoring it or restarting with a full enterprise model. ## What happens when the discipline is skipped When this discipline is skipped, the failure shows up in predictable ways. - Analysis that stops at the application layer and skips data reconciliation leads to two conflicting "Customer" or "Order" definitions being force-merged, producing duplicate records, lost order history, or silently dropped fields that downstream reporting depended on. - Analysis that skips the technology layer runs into contract and licensing surprises late in the project — a vendor agreement that legally can't be scaled to combined transaction volume until a renewal date, or a data-residency law that blocks hosting the merged customer data where the target platform runs — forcing a phased cutover that wasn't in the original plan. - Analysis that never revisits its initial scope boundary discovers only after committing to a data-layer decision that the entity it just redefined was quietly shared with marketing or finance systems outside the stated project boundary, requiring rework. ## Walking one merger through the layers A concrete scenario: two mid-sized e-commerce retailers merge and scope their first integration effort to order management. - **Business architecture work** confirms both companies want one shared order-capture-through-fulfillment process within a year. - **Data architecture work** then finds that one company's "Order" model supports partial shipments and split payments while the other's does not, and that both companies' "Customer" identifiers turn out to also be consumed by each company's separate marketing and loyalty systems — well outside the original order-management boundary. That discovery triggers an explicit scope expansion for the Customer entity specifically, without expanding the whole project to a full enterprise re-model. - **Application architecture work** then decides which order-management system to keep and how it will be extended to support partial shipments going forward. - **Technology architecture work** uncovers that one company's order platform runs under a vendor contract that caps transaction volume well below the combined companies' order volume and can't be renegotiated for eight months — which becomes the real constraint on the cutover date, regardless of how quickly the application and data work finishes.