Integrated Acquisition Capstone & Decision Key
Scenario
A company acquires another business. Both firms have overlapping Customer systems, different codes, hundreds of point-to-point interfaces, a new SaaS CRM, regulated personal data, and a requirement for near-real-time Order/Customer updates.
Build the DII response in order.
1. Plan & Analyze
Define:
- business, latency and service needs;
- security/regulatory/retention/lifecycle constraints;
- candidate source systems and ownership;
- actual source fitness through profiling;
- existing forward/backward lineage;
- business definitions, constraints, derivations and transformation rules.
Do not choose the integration tool before understanding the data and obligations.
2. Design
- define enterprise and solution architecture;
- choose interaction and latency patterns by requirement;
- reduce interface proliferation through reusable/canonical patterns where justified;
- model persistent and transient structures/messages;
- map source-to-target semantics;
- orchestrate order, dependencies, triggers, retry and recovery.
Separate Master/Reference semantic issues from transport mechanics.
3. Develop
- reusable services and executable flows;
- migration approach with repeated trials/reconciliation/cutover;
- publication approach for important new/changed data;
- event/CEP flows only where pattern recognition and immediate action justify them.
4. Implement & Monitor
Activate tested services and monitor to the service level required by dependent consumers. Maintain operational DII Metadata.
5. Govern
- business/Data Steward approval of transformation meaning;
- service-reuse and architecture reviews;
- Data Sharing Agreements for external exchange;
- security for data in motion and virtual access;
- reliable mapping, service-registry and lineage Metadata.
6. Measure
Use more than an interface count. Measure:
- availability of usable required data;
- volume/speed/latency;
- cost/complexity/reuse/usage.
Weak capstone answer
“Buy one integration platform and connect everything.”
This is weaker because it skips requirements, source evidence, semantic governance, mapping, orchestration, service obligations, migration controls, lineage and measurement.
Changed-fact capstone check
If the acquired environment contained only a few stable applications with identical semantics and low change, the enterprise architecture should remain proportionate; Chapter 8 does not require a hub or real-time pattern merely for uniformity.
Source boundary: DAMA-DMBOK2 Revised, Chapter 8, pp. 257–286.