TIBCO EBX Master Data Management 2 — Questions and Answers
Question 1: What is match and merge in TIBCO EBX and why is it used?
- An MDM process that identifies duplicate records across sources using configurable matching rules and merges them into a single golden record, eliminating redundancy in master data (Correct answer)
- A network protocol used to synchronise EBX cluster nodes
- A feature that combines two EBX Datasets into a single merged Dataset for reporting
- A git-style merge operation for combining EBX Data Model versions
Correct answer: An MDM process that identifies duplicate records across sources using configurable matching rules and merges them into a single golden record, eliminating redundancy in master data
Match and merge detects probable duplicate entity records using configurable similarity algorithms (phonetic, fuzzy, exact match), presents match candidates to stewards, and upon approval creates a single authoritative golden record.
TIBCO EBX's match and merge capability addresses one of MDM's core challenges: the same real-world entity often exists as separate records in different source systems, each with slight variations. EBX's matching engine compares records using configurable rule sets that apply similarity algorithms per field. The merged golden record retains the best-quality value per field (survivorship rules) and a cross-reference linking back to all source records.
Question 2: What is a Reference Data domain in TIBCO EBX and how does it differ from Master Data?
- Reference data consists of relatively static code sets and lookup tables (country codes, currency codes) shared across systems; master data represents core business entities (customers, products) that change more frequently (Correct answer)
- Reference data is only accessible by read-only consumers while master data supports full CRUD operations
- Reference data is stored in a separate EBX installation from master data
- Reference data requires no governance while master data requires full MDM lifecycle management
Correct answer: Reference data consists of relatively static code sets and lookup tables (country codes, currency codes) shared across systems; master data represents core business entities (customers, products) that change more frequently
Reference data (country codes, unit of measure codes, department codes) is slow-changing, shared lookup data. Master data (customers, products, employees) represents core business entities with richer attributes and faster change rates.
TIBCO EBX is designed as a multi-domain MDM platform that manages both reference data and master data. Reference data domains contain relatively small, slow-changing lookup tables — ISO country codes, regulatory classification codes, chart of accounts values — that are shared across many applications. Master data domains manage core business entities with complex attributes, relationships to other entities, and faster change rates.
Question 3: How does TIBCO EBX handle data hierarchy management?
- By supporting multi-level parent-child relationships within a dataset (e.g., product category trees, organisation charts) with inheritance of attributes down the hierarchy (Correct answer)
- By requiring a separate graph database to store hierarchical data linked to EBX
- By flattening all hierarchies into a single-level list before storage for query efficiency
- Hierarchies are only supported for geographic reference data, not for other domains
Correct answer: By supporting multi-level parent-child relationships within a dataset (e.g., product category trees, organisation charts) with inheritance of attributes down the hierarchy
EBX natively models hierarchical data (product taxonomies, cost centre hierarchies, org charts) as recursive parent-child relationships within a table, with built-in hierarchy browsers and the ability to inherit attribute values down the tree.
Hierarchical data management is a core EBX capability. EBX Data Models support self-referencing foreign keys that create tree structures within a single table. EBX's hierarchy browser presents these structures in an expandable tree UI. Attribute inheritance allows a parent node's values to cascade down to child nodes unless overridden. When the same entity must appear in multiple hierarchies simultaneously, EBX supports multiple overlapping hierarchy views over the same base master records.
Question 4: What role does TIBCO EBX play in a TIBCO integration architecture alongside BusinessWorks and TDV?
- EBX provides the authoritative master data that BW integration processes enrich messages with and that TDV exposes as a virtual data source, ensuring consistent entity data across all integration flows (Correct answer)
- EBX replaces both BW and TDV in a modern integration architecture
- EBX is only used as an internal system with no connectivity to BW or TDV
- EBX provides the messaging backbone replacing TIBCO EMS in data-heavy integrations
Correct answer: EBX provides the authoritative master data that BW integration processes enrich messages with and that TDV exposes as a virtual data source, ensuring consistent entity data across all integration flows
EBX is the master data authority: BW processes call EBX APIs to enrich transaction messages with golden records, while TDV federates EBX master data alongside operational data for unified analytics.
In a complete TIBCO data architecture, TIBCO EBX provides the governed master data layer. TIBCO BusinessWorks integration processes call EBX's REST API at runtime to enrich transaction messages. TIBCO Data Virtualization includes an EBX adapter, enabling TDV to federate EBX master data alongside transactional databases in unified analytical queries.
Question 5: What is the EBX Workflow engine used for?
- Modelling and executing multi-step governance processes for data change requests, including sequential approval steps, parallel reviews, and rejection loops with configurable participant roles (Correct answer)
- Executing BPMN business processes for customer-facing operations outside EBX
- Scheduling batch data imports from external systems into EBX on a cron schedule
- Managing the deployment pipeline for new EBX Data Model versions to production
Correct answer: Modelling and executing multi-step governance processes for data change requests, including sequential approval steps, parallel reviews, and rejection loops with configurable participant roles
EBX's built-in workflow engine models the governance lifecycle of data change requests — who reviews, who approves, escalation paths, and rejection handling — ensuring data changes follow a controlled process before becoming official.
TIBCO EBX includes a native workflow engine specifically designed for data governance processes. When a data change request is initiated, a configurable workflow process is triggered. The workflow models the full governance lifecycle through sequential or parallel steps, with approval and rejection routes. The complete workflow history is maintained alongside the data change in EBX's audit trail.
Question 6: How does TIBCO EBX support multi-domain MDM in a single platform instance?
- Multiple independent Data Models and Datasets for different domains (Customer, Product, Supplier, Location) coexist in a single EBX installation with separate governance, access control, and workflows per domain (Correct answer)
- Each MDM domain requires a separate EBX server installation and licence
- EBX supports only a single data domain per installation
- Multi-domain MDM in EBX is achieved by deploying a microservice per domain that calls the EBX API
Correct answer: Multiple independent Data Models and Datasets for different domains (Customer, Product, Supplier, Location) coexist in a single EBX installation with separate governance, access control, and workflows per domain
A single TIBCO EBX instance supports multiple independently governed MDM domains — Customer, Product, Supplier, Location, etc. — each with its own Data Model, security, workflows, and distribution configuration.
TIBCO EBX is architecturally a multi-domain MDM platform by design. A single EBX server installation can host dozens of independent MDM domains. Each domain has its own Data Model, Datasets, user roles and access permissions, workflow configurations, and API endpoints. Domains can have cross-domain relationships — a Product record can reference a Supplier record from the Supplier domain, and EBX enforces referential integrity across domain boundaries.
What is match and merge in TIBCO EBX and why is it used?