Learning Objectives
By the end of this lesson you will be able to:
- Define a Key Business Data Area (KBDA) in the PDM context
- Explain how KBDAs are derived from the Conceptual Entity Model
- Describe how KBDAs relate to legacy data stores, data owners, and migration planning
What Is a Key Business Data Area?
A Key Business Data Area (KBDA) is a grouping of related data entities that:
- Are owned by the same business function or data owner
- Are migrated together or in a defined sequence
- Share a common Data Owner who signs off their decommissioning
KBDAs are derived from the Conceptual Entity Model. The top-level entities in the model - Customer, Product, Equipment, Order, Supplier, Workforce, and so on - form the starting point. Related entities are grouped together based on business ownership and functional alignment.
KBDAs and Business Functions
KBDAs are not purely technical groupings - they map to business functions. This is important because it determines who the Data Owner is for each KBDA, and who must be involved in DQR meetings, System Retirement Plans, and go-live sign-off.
In the DHGS example, the KBDAs align with business functions:
| KBDA | Business Function |
|---|---|
| Equipment | Production & Maintenance |
| Site | Production & Maintenance |
| Workforce | Human Resources |
| Work Register | Production & Maintenance |
| Supplier | Supplier Management / Accounting |
| Product | Production & Maintenance |
| Order / Customer | Sales / Invoice Accounts |
| Vehicle | Vehicle Management |
These KBDAs are the top-level entities from the Conceptual Entity Model. Note that Equipment and Vehicle are technically the same entity type but are managed by different functions and have different regulatory and legal requirements, so they are decomposed separately. Financial data is not a KBDA in its own right - Finance is a business function that consumes the other areas, and the financial ledgers form their own Unit of Migration, loaded after year end.
KBDAs and Migration Sequencing
One of the most important outputs of KBDA analysis is the migration sequence, the order in which KBDAs are migrated.
The sequence is driven by dependencies:
- Customer must be migrated before Orders (each order must reference a valid customer)
- Products must be migrated before Order lines (each line must reference a valid product)
- Equipment must be in place before Work Registers (maintenance schedules depend on equipment records)
The DHGS analysis identifies Customer as a good early candidate because it is relatively self-contained and the policy of concentrating on the 200 largest customers reduces the volume. Equipment is a later candidate because of its complexity and interdependencies.
Policies and KBDAs
Policies set constraints on how each KBDA is migrated. Examples from DHGS:
- MDM policy for Customer: a single de-duplicated customer list is required. This generates a DQR to manage deduplication before migration.
- Regulatory policy for Equipment: safety-at-work and data protection requirements apply. Equipment records must be complete and accurate.
- Local policy on small customers: DHGS wants to dispose of smaller wholesale customers. This means they are excluded from migration, an exclusion rule in the ETL.
Policies are captured in the MSG and flow through to the mapping rules, DQR process, and migration design.
Key Takeaways
- KBDAs group data entities by business ownership and functional alignment
- Each KBDA has a Data Owner who is responsible for sign-off at key stages
- KBDAs drive migration sequencing - dependencies between KBDAs determine the order of migration runs
- Policies apply at the KBDA level and feed directly into ETL exclusion rules and DQR priorities
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT): Chapter 7, “Metadata and Key Business Data Areas”.