Customization and Extension Framework

The canonical model is intentionally designed to allow controlled customization without compromising the standardized architecture. A structured framework manages extensions that maintains consistency across implementations and subject areas.

Level 0: No Customization (Strict Canonical)

Use the canonical model exactly as defined. Apply only standard transformations. When to Use: When subject areas perfectly match canonical definitions. Scope: No structural changes; configuration only through metadata tables. Example: Party subject area typically requires minimal customization.

Roles played: Professional Services Teams (PS) Teams leads vanilla implementation as per the Redbook with consultation with Development Engineering (DE), the HCL CDM platform development team, for any support needed.

Level 1: Attribute Extension (Low Impact)

Add new attributes to existing canonical entities using the flexible ATTRIB_* columns. When to Use: When adding a few client-specific or domain-specific attributes. Scope: Limited to 5 flexible attributes per entity (attrib_1 through attrib_5). Example: Adding a "customer_segment_code" attribute to the Party entity.

Roles played: Tech BA - Gaps identified through foundation layer for attributes to be added. DE - Identifies requirements, changes the model, generates LDZ-RDV code through metadata model. Implementation Team - Works with Tech BA / DE team, develops ETL accordingly.

Level 2: Relationship Extension (Medium Impact)

Existing Reference values don't map with the client-specific values and GAP identified to make changes accordingly. When to Use: Inherent reference data values (e.g. account type) have a separate reference set from the client side. Scope: Map the reference values with existing ones and generate any snippet changes. Example: Event names need to be clubbed and mapped to standardized form for 360 calculations.

Roles played: Tech BA - Gaps identified through foundation layer that identifies impact on existing Reference data. DE - Analyzes overall impact and lists plan of action with estimated changes required. Implementation Team - Works with Tech BA / DE team to understand the development requirement.

Level 3: Entity Extension (High Impact)

Add entirely new entities (Hubs) not in the canonical model. When to Use: When a completely new subject area or business entity is required. Scope: Creates new Hub table with corresponding Link and Satellite tables. Example: Adding a Partner/Vendor entity for B2B use cases.

Roles played: Tech BA - Gaps identified through the foundation layer for additional entities and relationships. DE - Identifies model changes, works with Stakeholders and BA to finalize the changes, generates LDZ-RDV code through metadata model. Implementation Team - Works with DE team to review, finalize, and develop ETL accordingly.

PS Team - ETL Pipeline Performance

ETL pipeline performance varies by client environment and implementation design. Key factors include data volume, infrastructure size, database platform, storage architecture, workload concurrency, resource allocation, and SLA targets.

The implementation provides standard optimization practices and recommended processing patterns out of the box. During implementation, the PS team may further tune performance through workload balancing, indexing, infrastructure scaling, and execution-level optimizations to align with client-specific operational requirements and SLA targets.