Implementing ON EBX: A Technical Blueprint for Customer MDM

EBX earns its place in a customer domain for a reason that is easy to state and easy to underrate: the model is the product. You can stand up a governed, versioned, permission-controlled data model in EBX faster than in almost anything else on the market, you can hand the model itself to the business, and you can change it without a release train. Layer on a permission system that resolves across five levels down to the individual field, dataspaces that give change control real teeth, and a workflow engine built for stewardship rather than bolted alongside it, and you have a platform that suits a customer master unusually well. A customer master is never finished, and the things that change most often are the model, the rules, and the people who own them.

Customer data still arrives the way customer data always arrives: eleven systems that each believe they own the truth about the same person, names spelled four ways, addresses that were free text until a migration nobody documented, and a consent flag whose meaning is contested. Turning that into a golden record is a design exercise, and this paper is the design. It assumes EBX 6.2.x, a party domain with real duplicates in it, and a stakeholder who will eventually ask you to prove the golden record is right. It covers self-managed and managed deployment, it names the decisions that are expensive to revisit, and it is specific about where the reference architecture extends beyond the hub into enrichment, publication and monitoring, because those integration points are where effort estimates usually go wrong.

One point of vocabulary before anything else. As of March 2026 the platform is delivered by ON EBX, an autonomous business unit inside Cloud Software Group with its own general manager and a research and development budget spent only on EBX. The product is still called EBX, the documentation still says TIBCO EBX in places, your contracts are unchanged, and the add-ons are now styled EBX Match and Merge rather than TIBCO EBX Match and Merge. Use EBX in your design documents and stop worrying about it.

1. What the ON EBX split changes, and what it does not

The announcement on 26 March 2026 carved EBX out of TIBCO into a dedicated business unit under general manager Philippe Assuncao, with stated engineering priorities of AI-powered data governance and agent-ready architectures, and with existing contracts, support agreements and roadmap commitments explicitly carried over. Read as a customer, this is a good outcome: a product that spent eight years as one line item in a large integration portfolio now has a team whose only job is to ship it. Read as an architect about to commit a customer domain to it, almost none of it changes your design. Entity resolution economics, steward capacity and model governance do not care who owns the vendor.

What does shape your plan is the version floor. Support for EBX 6.2.0, for the 6.1.x releases and for 5.9.26 and below runs to 31 May 2027, and the reason behind that is a sound one: critical third-party libraries, Spring among them, issue security patches only for Jakarta EE compliant versions, so the older branches cannot be kept current no matter who maintains them. The supported target is 6.2.1 or later, which in practice means 6.2.3, released in April 2026. That brings Jakarta EE 10 or above, a current LTS Java runtime, and an application server floor around Tomcat 10, WebSphere Liberty 23 or JBoss 8. Custom Java is recompiled against the renamed packages, and the REST toolkit and the mail API are the two areas that most often need attention.

There is a second, more practical consequence worth noting in week one. The documentation and download estate is moving onto ON EBX hosts as the new business unit stands up, so links your team has accumulated over the years will change. The cheap mitigation is to pull the PDF reference manual, installation guide and migration guide for your exact target version into your own document store at kickoff, and to cite version-pinned references in design artefacts rather than a floating latest URL. It takes an hour, and it keeps design discussions anchored to what the product does rather than to what somebody remembers.

2. What an EBX repository actually is

Four words carry most of the design weight in EBX, and getting them straight in the first week saves an argument in the third month. A repository is the single back-end store holding everything EBX manages, organised into dataspaces. A dataspace is a container of datasets that behaves like a branch: you create a child from a parent, it initialises with the parent's state, it is modified independently, and it is compared and merged back. A snapshot is a static, read-only capture of a dataspace at a point in time, which you can view or restore from but not edit. A dataset is an instance of a published data model, and a data model is an XSD-backed structural definition built in the Data Model Assistant that must be published before any dataset can exist on it.

Dataspaces are the capability that most distinguishes EBX from the rest of the category, and they repay being scoped deliberately. They are exceptional at what they were designed for: a proposed change set to a model or to reference data, reviewed and approved as a unit, merged once the business signs it off, with a snapshot proving what the world looked like beforehand. For high-volume operational customer records the platform's own guidance points you in a different direction, and two notes explain why. Repeated create-merge-delete cycling consumes repository resources and fragments the internal structures that hold dataspaces, so the recommendation is to use a transactional procedure where all you need is isolation, and to schedule database reorganisation on large repositories. And matching operations are not designed to run simultaneously in child dataspaces, which shapes the stewardship pattern in section 11. The rule that falls out is a clean one: use dataspaces for governed change, and steward the customer table in place.

Dataset inheritance is the second capability worth understanding precisely, because it is powerful exactly where it belongs. Declared in the model, it resolves a value by looking at the local dataset first, then walking up the parent chain, then falling back to a declared default. Records come in four modes: a root record, an overwriting record, an inherited record, and an occulting record that deliberately hides a parent record carrying the same primary key. Field inheritance is a separate mechanism resolved through a foreign key path, and it takes priority over dataset inheritance where both apply. For reference data this is a gift, and it is one of the reasons EBX is so strong in that domain: you model the global code list once and let each region overwrite the handful of values it is legally obliged to differ on. On the golden customer record itself, prefer explicit values, because provenance you can state in one sentence is worth more there than the economy inheritance buys.

The permission model is where EBX quietly outclasses much of the market, and it is worth designing deliberately rather than discovering. Permissions resolve across five levels, from dataspace down through dataset, table, record and finally field, and they resolve restrictively: at any level a user cannot hold a higher permission than the one resolved at the parent level. Access is write, read-only or hidden. On top of the declarative layer you can implement programmatic access rules, service activation rules and service permission rules in Java, and where restricted rules exist the minimum permission across them wins. For a customer domain that spans jurisdictions this is the mechanism that lets you keep one physical model while showing a German steward a different set of fields than a steward in Singapore, without building two hubs. Design it against a written matrix of role, region and field sensitivity before you build screens, because retrofitting field-level restriction after the stewardship UI is signed off means reopening the UI.

3. The first architectural fork: semantic or relational persistence

Before you model a single field, understand that EBX offers two ways of storing your data in the same repository, and that the choice is per table rather than per system. Semantic mode is the default and the governance-rich one: content lives in EBX's own generic internal structures, which are not meaningfully readable by SQL, and in exchange you get the full apparatus of dataspaces, snapshots, inheritance, history, programmatic constraints and validation. Relational mode is a mapped mode that persists master data directly into database tables you can query, and it is explicitly intended for current-time tables and tables regularly updated by external systems.

Relational mode makes a clear trade, and it is worth reading in full before you choose it. From a relational dataspace you do not get dataspaces or snapshots, dataset inheritance or inherited fields, table history, or user-defined attributes, programmatic constraints are not available, aggregated lists are not supported, and foreign key validation becomes blocking. Relational mode buys database-native scale by setting aside the branch, snapshot, inheritance and custom-rule machinery that a stewardship process leans on. That is the trade, stated plainly by the product, and the right response is to make it table by table rather than picking a side for the whole hub.

A related fact shapes every conversation you will have with a data platform team. Three kinds of object in an EBX repository are directly readable by SQL: relational-mode master data, history tables, and replica tables. Semantic-mode content lives in EBX's own optimised structures and is reached through the engine. So when an analytics lead asks to point a warehouse at the customer hub, the answer is that they read a replica published deliberately for that purpose, which is the better arrangement in any case because it gives you a stable interface and a single place to control exposure. Direct SQL writes to the repository are not supported in any mode, and that belongs in the database access policy rather than in folklore.

One more piece of context, because it supersedes a lot of inherited advice. EBX 6.0 reworked data persistence from the ground up. Data is no longer loaded into a Java cache at startup; it is indexed into Apache Lucene indexes persisted on the filesystem, so indexes are not rebuilt in memory on every restart and the validation report is itself persisted rather than recomputed. That is a substantial improvement in startup and restart behaviour, and it means any sizing spreadsheet inherited from a 5.9 project needs revisiting: the heap assumptions no longer apply and the new variable is filesystem capacity and latency for the index directory. Version 6.2.3 also added storage compression, which the release notes put at a ten to twenty-five per cent reduction in duplication for fresh imports and as much as ninety per cent for modified data. Ask ON EBX for current index sizing and disk throughput guidance at your record volumes, since it is the newest part of the architecture and the single most consequential input to sizing a large party table.

4. Deployment, topology, and how EBX scales

EBX has a clear and deliberate scaling model, and understanding it early makes the topology conversation straightforward. A repository is served by a single engine holding exclusive ownership of its relational database, which gives the hub one authoritative write path and removes a whole class of distributed-consistency problems from a domain where consistency is the entire point. Scale-out happens on the read side, and EBX provides two purpose-built mechanisms for it. Table replication projects governed data into database tables so that analytical and reporting consumers query at database speed without touching the engine. D3 broadcasts approved snapshots to replica nodes for local read performance across regions. High availability is configured as a main and standby pair, with the standby activated explicitly when it is needed. Design to that shape from the start and the architecture is simple, predictable and easy to reason about.

Two things are worth confirming with ON EBX for your exact version, because the documentation estate moved hosts during 2026 and the persistence layer was rewritten in 6.0: the current supported clustering configuration, and the expected recovery time when a standby node takes ownership. The second is the one that matters operationally. With indexes now persisted to the filesystem rather than rebuilt in memory, recovery time is largely a function of how quickly a standby comes up warm, and that is a figure only your own hardware can give you. Measure it during performance testing and write it into the recovery plan rather than estimating it in design.

Three deployment shapes are available and each suits a different kind of organisation. A self-managed web application on Tomcat, Liberty or JBoss over Oracle, PostgreSQL or SQL Server is the best-documented path and gives you full control of JVM, filesystem and database tuning, which matters more on EBX than on a typical platform because so much of the performance work is model design and database configuration. Container Edition deploys EBX on Kubernetes through Helm, validated on AKS, EKS, OpenShift and MicroK8s, with single sign-on, bearer authentication, SCIM, LDAP, JNDI data sources and mail sessions all configurable through environment variables, which is what makes a genuinely repeatable environment build possible. And a managed cloud service removes the operational burden altogether. Because the cloud offering has been evolving under ON EBX, confirm its current specification with them for your region rather than working from older published material.

If the managed service is your preference, five questions turn a good vendor conversation into a firm design basis. What is the upgrade cadence, and how much notice accompanies it. How is custom Java packaged and deployed. Which add-ons are included, given that Match and Merge and Data Exchange are effectively core to a customer domain. What is the environment model for development, test and production. And what is the outbound network path and latency for calls to an enrichment service, since section 7 puts one in the architecture. Ask these early, because the answers shape the integration design rather than merely documenting it.

Whatever shape you choose, environments are separate repositories rather than dataspaces within one repository. This is worth stating because the branch metaphor tempts teams into using a dataspace as a test environment, which mixes test data into production storage and makes a clean promotion impossible. EBX 6.1 introduced native staging for migrating configuration and artefacts between environments, and it should be the mechanism you standardise on. Hand-carried archives and manual reconfiguration are how a hub arrives at the state where nobody can say with confidence what differs between test and production, which is the state in which every incident takes three days to diagnose.

5. Modelling the party domain so it survives republication

The shape of a customer model in EBX is not exotic. You need a party table separated into person and organisation, either as two tables or as one table with a discriminator and conditional validation, and I would separate them, because the matching rules for a human being and a legal entity share almost nothing and a single decision tree serving both becomes unreadable within a quarter. You need an address table, a contact point table for email and telephone, an identifier table for tax numbers and customer numbers and loyalty numbers, a relationship table for household, hierarchy and employment links, and the reference code lists that give all of them meaning. What matters is less the entity list than three decisions layered on top of it.

The first decision is to model source records and a crosswalk as first-class objects, and this is a place where the model-driven nature of EBX works firmly in your favour. Because you design the model rather than inherit a fixed one, you can shape lineage to your domain precisely: a source party table holding each system's assertion as received, and a crosswalk table tying each source record to its golden record with source identifier, source key, first seen, last seen and current status. Design it that way and the question of which system said this person's surname was Van der Berg, and when, has a one-query answer. Let the load process overwrite the golden record in place instead, and the same question has to be reconstructed from history that may no longer exist upstream. It is perhaps two dozen fields of design work at the outset, and it is the difference between a hub you can defend at a data subject access request and one you cannot. Model it on day one.

The second decision is to keep computed fields for presentation and to persist anything the golden record asserts, and it runs against the instinct of an experienced EBX modeller. A computed value declared through a value function is elegant, keeps the model tight, and always reflects current inputs; on a reference data set it is exactly the right tool. On a customer golden record, three of its properties argue the other way. Computed values are resolved at read time, so they are not persisted, not historised, and not carried into table replication. Put survivorship logic there and the golden record cannot be published to the warehouse, cannot be shown as it stood last March, and does not appear in the audit trail. There is a performance argument as well: computed values sit alongside programmatic constraints, inherited fields and dynamic facets as nodes whose dependencies cannot be inferred, which is what makes validation heavier beyond roughly one hundred thousand records. So persist the survivorship result into real fields. Compute for display, assert in storage.

The third decision is to treat model republication as a data migration event, which is the product's own recommendation and worth carrying into your release checklist verbatim: a data migration plan must be set up and operated before the new data model is published. The reason is that the two persistence modes evolve differently by design. Semantic mode is intentionally flexible and non-blocking, so a primary key definition can be changed freely and the migration responsibility sits with you; existing records that do not satisfy the new definition are not loaded, which is precisely the behaviour you want when the migration is planned and a surprise when it is not. Mapped mode is restrictive and will block an evolution that would violate the integrity of existing data. In practice this means every model change to a populated table gets rehearsed against a restored copy at production volumes, with a record count reconciliation either side, and no exemptions for changes that look cosmetic. Widening a field is cosmetic. Redefining a key never is.

Two smaller modelling rules save real pain. Aggregated lists are for small volumes of simple data, on the order of one or two dozen entries; anything that can grow must be a declared table, and a customer's addresses can always grow. And in mapped mode, string fields require an explicit maximum length, password-typed fields are ignored, and the underlying database column count ceiling applies, so a wide denormalised table designed for matching convenience can fail to compile for reasons that have nothing to do with EBX.

6. Load first, match second, and never at the same time

The Data Exchange add-on is how bulk data gets into an EBX hub, and there is a naming trap to clear first. The current add-on is the reworked Data Exchange, whose documentation pages are labelled with the word new; the older generation still ships alongside it in EBX 6 as the legacy version, with configuration migrated automatically. Design against the current one. It handles CSV, Excel, XML and SQL sources, generates data models from XML, Excel and DDL files, and interposes a semantic model between source and target so that mappings are declared rather than coded. For structurally similar sources it will propose a mapping with no setup at all; for genuinely disparate sources you define a custom mapping with field splitting and aggregation and cross-reference tables for value conversion, and you drop into the Java API only for transformations that cannot be expressed declaratively.

Confirm the source list against your actual upstream before you design the ingestion layer. CSV, Excel, XML and SQL are documented and certain. JSON, object storage and streaming sources are not confirmed in the public documentation, and if your upstream is a lakehouse exporting Parquet then you need a conversion step in the pipeline and you should find that out in design rather than in build. This is a five-minute question to your vendor contact that regularly saves a fortnight.

The constraint that shapes every load design is the transaction ceiling. EBX guidance puts the practical limit around ten thousand atomic updates in a single transaction, beyond which you decompose the work into multiple procedure executions with explicit commit thresholds. At customer volumes chunking is not a tuning refinement, it is the design. Two related behaviours are worth knowing while you size the chunks. Transaction cancellation resets the loaded indexes of every modified table, forcing a rebuild, so a load process that routinely rolls back is quietly paying for itself twice. And the fetch size in mapped mode differs by database, with PostgreSQL configured to fetch the entire result set, which means a naive read of a large relational-mode table can exhaust memory rather than degrade gracefully. Both are the kind of thing that behaves perfectly in a fifty thousand row test and falls over in the first full load.

The sequencing rule is simple and frequently broken: load everything, reconcile the counts, and only then match. Matching against a partially loaded table produces clusters built on absent evidence, and those clusters do not politely correct themselves when the rest of the data arrives; they leave behind merge decisions and matching metadata that has to be purged and redone. Use the import simulation and error reporting capability as a gate before the real run, reconcile row counts and null rates against source extracts, and treat the reconciliation report as a deliverable that somebody signs. Also note the operational rule that matching operations should not run simultaneously in child dataspaces, which means your load and match schedule is a single serialised pipeline rather than a set of parallel per-source jobs.

7. Standardise and enrich before you match

Address verification, postal validation and name standardisation are a specialist market, and no master data platform in the category replicates them internally. Informatica, Reltio, Stibo, Semarchy and EBX all take the same architectural position: the platform masters and governs the data, while postal reference data, deliverability checks and demographic or firmographic enrichment come from providers who maintain that reference data as their entire business. Loqate, Melissa, Experian and Precisely exist because keeping global postal data current is a full-time undertaking that no MDM vendor should be duplicating. The question for an EBX design is therefore not whether an enrichment service belongs in the architecture, because it does, but where in the pipeline it sits and how cleanly it integrates.

EBX brings three capabilities of its own to data quality, and they are worth using deliberately before reaching for anything external. Model-driven validation rules and constraints enforce structure and business logic at the point of write, so non-conforming data is rejected rather than reported on later. The Insight add-on profiles data against quality dimensions such as completeness and accuracy and surfaces them as dashboards and indicators with drill-down, which turns data quality from an opinion into a measured trend a data owner can act on. And Match and Merge provides configurable fuzzy, phonetic and exact comparison for duplicate detection. Between them, those three cover conformance, measurement and resolution, which is the right scope for a governance platform and a sensible boundary to draw.

Place the enrichment service upstream of the hub, in the ingestion pipeline, before records are loaded. Standardising in the pipeline gives you batch throughput, lets you cache and reuse verification results across sources, and keeps the hub's write path independent of any external service's availability. A synchronous call-out from inside EBX is the right pattern at interactive volumes and the wrong one during a bulk load, because it couples every record write to an external round trip. Persist both the address as it was given and the standardised components, along with a verification status, a verification timestamp, and the provider and reference-data version used. That last field looks like bureaucracy until the first time a provider refreshes its reference data and a thousand addresses legitimately change status, at which point it is the only way to explain what happened.

There is one legitimate case for a call-out inside EBX, which is the interactive path: a steward or a service creating a single party who should be told immediately that the address is not deliverable. Build that as an explicit user service or a script-invoked call with a short timeout and a defined degradation path, so that when the provider is unavailable the record is created with an unverified status and queued for later verification rather than blocked. A hub that cannot create a customer because a third-party API is down will be worked around within a week, and the workarounds are always worse than the outage.

The AI Assistant, available since 6.2.2, is worth designing into the stewardship experience rather than treating as a novelty. It generates suggestions from record data, with documented uses spanning text generation, summarisation, translation and format standardisation, configured through a language model provider, an external service configuration holding the endpoint and credentials, and per-table assistance functions that reference input and virtual fields through placeholder syntax. Two design notes follow. By design EBX connects to the provider of your choice rather than embedding one, which is the same separation of concerns as the enrichment service above and leaves you in control of which provider sees your data. On a party table that control needs to be exercised deliberately, with a vendor assessment and a data protection impact assessment completed before the feature is switched on. And because format standardisation by a language model is generative, point it at inconsistent casing, phone formatting and free-text tidying rather than at postal validation, which belongs with the reference-data provider. Used for what it is genuinely good at, it takes real friction out of a steward's day.

8. Designing a decision tree a data owner can defend

Matching in EBX is configured as a matching policy attached to a registered table, and the heart of the policy is a decision tree. Get the vocabulary right, because it differs from every other platform in the category and the difference matters when you are reading vendor documentation under time pressure. Each node in the tree declares an evaluation method, which is one of all fields match, at least a given number of fields match, a weighted average, or a direct operator comparison. Each field within a node declares a comparison mode, either an algorithm producing a similarity score or an operator such as equals, either null, both null or both not null. Each field carries a minimum score expressed as a percentage and a weight from zero to one hundred, where a weight of zero excludes the field entirely. Every path through the tree terminates in one of three outcomes: match, suspect, or no match. Before any of this runs, a pre-clustering phase driven by search strategies groups plausibly similar records so the expensive comparisons are not run across the whole table.

EBX matching is deterministic and rule-based by design. Every available algorithm is a classical string, phonetic, exact or range comparator, scored and thresholded entirely according to configuration you control. That design choice buys something increasingly valuable: the matching logic is fully explainable. You can put the decision tree in front of a data owner, they can reason about it without a data scientist in the room, and the add-on will return an explanation of how a specific pair traversed the tree and what it scored. In a domain where a merge decision may have to be justified to a regulator, an auditable rule beats an opaque probability. The corresponding commitment is that accuracy is a configuration discipline you own continuously, and that steward corrections sharpen the rules only when someone carries them back into the tree. That is the argument for staffing a named match owner for the life of the hub, rather than treating match configuration as a build-phase task that ends at go-live.

The add-on's own performance guidance is unusually candid and should be treated as design input rather than a tuning appendix. Test a matching policy against a subset of fewer than fifty thousand records before you point it at a large table. Allocate only about half the application server's memory to the JVM and leave the rest to the filesystem cache, which makes sense once you remember that indexes now live on disk. The pre-processing phase parallelises across CPUs, so cores matter more than they used to. Prefer the code-oriented search strategy for identifiers, dates, telephone numbers and email addresses, where the whole value is indexed as a single token, and at volume switch that strategy's operator from contains to starts with. Assign a weight of zero to low-cardinality fields such as booleans, flags and short enumerations, because they contribute noise and cost. Configure stop words to exclude high-frequency tokens. And do not allow placeholder values such as not applicable, a single character, or a row of x characters to stand in for nulls, which is a data preparation requirement rather than a matching setting and belongs in the standardisation step described above.

One item on that list has architectural consequences and deserves its own paragraph. Matching across related tables or business objects significantly impacts performance, and the vendor's recommendation for mid-to-large datasets is to denormalise into a single-table policy. Taken naively, that instruction destroys the normalised party, address and contact model you have just carefully designed. Do not take it naively. The right resolution is to keep the governed model normalised and to maintain a purpose-built match projection alongside it: a flattened table carrying only the fields the decision tree needs, refreshed as a step in the load pipeline, matched against, with cluster and golden assignments written back to the governed tables. You get the matching performance and you do not deform the model that stewards and downstream consumers see. The cost is one more artefact to keep in step, which is a far smaller price than a match run that cannot finish inside its window.

Matching can be executed manually, after submission, before creation, or inline against newly created and updated records, and the programmatic surface is richer than the configuration screens suggest. There is a synchronous single-record match for interactive use, an asynchronous whole-table match that returns a process handle you can track, an asynchronous match over a filtered subset that accepts an expression, a non-persistent simulation that can be run either against an existing record or against a set of supplied field values, an evaluation call that returns an explanation of how two records traversed the decision tree, and a way to retrieve records that matched nothing. The one worth designing into your integration architecture deliberately is the non-persistent simulation against supplied values, because that is a duplicate-prevention service you can expose to every capture system upstream. Stopping a duplicate at the point of creation costs a fraction of merging it later, and it is the only intervention in this whole architecture that reduces steward workload over time rather than redistributing it.

9. If you cannot measure the match, you are not tuning it

There is no published throughput benchmark, no maximum table size and no records-per-hour figure for EBX matching anywhere in the documentation, and you should stop looking for one. Sizing is established by proof of concept against your own data, and quality is established against a labelled set you build yourself. Neither is optional and both are routinely skipped, which is why so many hubs go live with a match configuration whose accuracy nobody can state.

Build the labelled set from your own data, not from a synthetic generator. Two to five thousand record pairs is enough if they are chosen deliberately rather than randomly, and the stratification is where the value is. Include the obvious duplicates that any rule catches. Include near misses. Include the cases that must not merge, which are the ones that expose a bad rule: siblings at the same address, a father and son sharing a name, two subsidiaries of one group at one registered office, a married couple with a joint account, a landlord and a tenant. Include records with missing fields, records with non-Latin names and transliterations, and records that arrived from the systems you trust least. Then have two people label them independently and send the disagreements to the data owner for adjudication. That adjudication session is the single most valuable meeting of the entire programme, because it forces the business to state what the same customer means, and in my experience they have never written it down before being asked.

Then measure three things and publish them. Precision is the share of pairs the engine called a match that really were matches. Recall is the share of true duplicate pairs the engine found. Suspect rate is the share of pairs routed to a human, and it is the number that determines whether your stewardship model is affordable. The asymmetry between the two error types is the thing to internalise: a false merge fuses two real people into one record, which is a privacy incident, a potential regulatory disclosure, and an unmerge exercise that may not be cleanly reversible, while a missed duplicate is an annoyance and a slightly wrong count. Tune accordingly. I would not switch on automatic merge below ninety-nine per cent precision on the labelled set, would treat any false merge in the labelled set as a release blocker rather than a metric, and would accept recall in the low nineties for the sake of that precision. Set the suspect threshold to the steward capacity you actually have, rather than deciding the threshold and then discovering the queue.

10. Survivorship and the trust hierarchy

Merging in EBX is governed by a merge policy, linked to the matching policy, which decides whether a new golden record is created automatically and how each field's surviving value is chosen. The policy carries a survivorship strategy, per-field survivor configuration, handling for related tables and foreign keys, and a flag marking one policy as the one used for manual merge, which pre-selects values in the steward's merge view that the steward may then change. Rules come in two shapes, one selecting which record wins and one deciding how a field's value is composed, with a constant option available for text fields. Recent versions added golden-record creation modes distinguishing parent from child entities, and record lineage surfaced in toolbars and workflows, which is worth switching on because it is the fastest way for a steward to answer the question of where a value came from.

Underneath the strategy sits a trusted source ranking. One survivorship option picks the value from whichever source holds the highest trust rank, and field-level trust configuration takes precedence over the table-level ranking, which is what allows the billing system to win on legal name while the digital channel wins on email preference. Build that ranking field by field with the data owner in a workshop and write it down, because the resulting document turns out to be the most frequently consulted artefact of year two, and reconstructing it from configuration screens eighteen months later is miserable work.

The most consequential single setting in this section is where the data steward's own decision sits within the trust ranking, because it determines whether human judgement persists. The ranking includes a built-in pseudo-source representing the steward's choice. Rank it at the top and a steward's decision wins every subsequent merge, permanently, which is what you want in the large majority of cases: you appointed stewards for their judgement, and a hub that preserves it earns their engagement quickly. Rank it below the source systems and an inbound load will reassert the source value over the correction, which is right for a small set of fields and confusing everywhere else. So set the default in the steward's favour and treat every exception as a deliberate, documented choice: a legal entity name that must mirror a registry, a tax identifier that must mirror the filing. Give each exception a named owner and a sentence of justification, and tell stewards plainly which fields they own outright. Configured this way, the trust hierarchy becomes the clearest statement your programme makes about who decides what.

Two things are worth establishing for your version before design freezes. The first is the full set of survivorship functions available to you, which determines whether rules such as most recently verified or longest non-null value are expressed declaratively or want a small amount of custom logic. The second is how unmerge behaves in your configuration: how a golden record separates back into its constituents, and what happens to identifiers that downstream systems have already stored. You will use unmerge, because every customer hub does and usually within the first quarter, so rehearse one in the test environment before go-live and document exactly what it leaves behind. It is a thirty-minute exercise that saves a difficult afternoon.

11. Stewardship is a capacity plan, not a screen

EBX has a genuinely capable workflow engine and it is one of the strongest reasons to choose the platform for a governed domain. Workflow models are composed from five step types: user tasks that generate work items for people, script tasks that run without human involvement, conditions for routing, sub-workflow invocations that can be resolved statically or dynamically, and wait tasks that block until an event arrives. Each workflow carries a data context of variables that steps read and write. Work items are offered to roles or to named users, and the operational furniture that decides whether a stewardship function actually functions is all present: progress strategies that either show a work item list or open the next step automatically, templated email notifications, reminders, and deadlines expressed as absolute or relative dates that fire notifications when missed.

Workflows can be launched from a table trigger through a built-in launch mechanism, and they can be started, resumed and ended through data services, which means an upstream system can open a stewardship case without anyone logging in. Use both, and resist the temptation to build a workflow model per scenario. Four or five models covering duplicate adjudication, new-party approval, data change request and periodic review will carry a customer domain for years; thirty models covering every variation become an unmaintainable estate that nobody dares to change, and the variation belongs in conditions and data context rather than in separate models.

There is a design question here that the platform's own idioms answer misleadingly. The canonical EBX pattern is to scope a workflow to a child dataspace, curate inside it, validate, and merge back to the reference dataspace, and that pattern is exactly right for model changes and reference data change sets, where the unit of approval is a batch of related edits. For the operational customer table I would not use it. Section 2 gave the two reasons: matching should not run concurrently in child dataspaces, and heavy dataspace creation and deletion fragments internal repository structures. Steward the customer table in place, using record-level permissions and workflow state to control who can change what and when, and keep branch-and-merge for the governance of the things that genuinely change as a set.

Then treat the whole thing as a capacity plan, because that is what it is. Multiply your suspect rate by the volume you expect to load and by the realistic minutes a person needs to adjudicate one case, and you have a full-time-equivalent number. Compare it to the people you actually have. If it does not fit, the correct response is to change the threshold or invest in prevention through the duplicate-check service described in section 8, not to hope the queue drains. Instrument time to decision from day one, set deadlines and reminders on the work items, and watch the queue depth trend rather than its absolute value. A queue that grows monotonically for two weeks is telling you the threshold is wrong. It is not telling you the stewards are slow.

One capability worth knowing about while you design governance, because its home changed with EBX 6. Business glossary and catalogue functions now sit in the metadata management introduced in 6.2, which brings a data catalog and governance documentation into the core product alongside lineage rather than into a separate add-on. For a customer domain that is the better arrangement, because glossary terms, the model they describe and the permissions over both live in one place and move together. Confirm the current feature set against your version and decide early how far you intend to take it, since some organisations will still want a dedicated enterprise catalogue alongside the hub, and that is a budget line rather than an afterthought.

12. Publishing mastered data downstream

EBX publishes mastered data through three deliberate mechanisms rather than a single event bus, and once the shape is clear it is a coherent architecture. Table replication projects governed data into real database tables, giving analytical and bulk consumers database-speed access without touching the engine. SOAP and REST data services, generated from the model rather than hand-built, serve synchronous application reads and writes. D3 broadcasts approved snapshots to replica EBX nodes for regional read performance. Alongside those sit CSV and XML services for extracts and programmatic procedures for anything bespoke. The one element to plan for explicitly is the outbound change feed: EBX does not emit its own message stream, so where your target architecture shows customer events flowing to subscribers, you compose that from replication plus the change-data-capture tooling your platform team already operates. It is a well-trodden pattern that works well in production. It is simply a workstream to scope in design rather than a switch to flip at integration time.

The cleanest way to build the change feed, and the reason the capability exists, is table replication. You declare a replication unit in the data model, naming a target dataspace and dataset, with a refresh policy that is either on commit, keeping the replica continuously current with its source table, or on demand, refreshed by a service call, a user action or the API. The replica lands as real database tables carrying technical columns for creator, last modifying user, creation date and last write timestamp, and that last write column is your change-data-capture watermark. Point your existing CDC tooling at the replica and you have an event stream built from components your platform team already operates, with no custom code in the write path. Four constraints are worth knowing at design time: the target cannot be a snapshot or a relational dataspace, computed values are resolved at read time and so are not replicated, field inheritance works with on-demand refresh, and a large refresh consumes undo and redo space, which on Oracle is a conversation to have with the DBA before the first full load rather than during it.

Design the replica as a published interface rather than an internal implementation detail, because access to it is governed by the database rather than by the engine. The field-level permissions from section 2 apply within EBX, so a replica should carry a deliberately restricted projection of the columns a given audience is entitled to see, with read-only grants issued administratively and audited like any other data access. Done this way you gain two useful properties: consumers are insulated from model refactoring, and the permission boundary is explicit and reviewable. Write the decision down, including which columns were deliberately excluded and why, so that the person who later adds three columns to unblock a report understands they are amending a published interface rather than tweaking a view.

Whichever mechanism you choose, publish a contract rather than a payload. Consumers should bind to a named, versioned view with documented field semantics and a stated refresh guarantee, not to whatever columns happen to exist in a replica this quarter. In practice that means one published customer view per consumption pattern, an explicit statement of whether it is eventually or immediately consistent, a stable external identifier that survives merge and unmerge, and a deprecation policy. The generated nature of EBX data services helps here, because the SOAP and REST surfaces are derived from the model rather than hand-built, and 6.1 added entity names precisely so that references do not have to use raw table paths. Use them. A consumer bound to an internal path is a consumer who breaks the next time somebody reorganises the model.

13. The non-functional track

Validation is the operational characteristic to design for, and EBX gives you the levers to keep it fast. Validation is incremental: the first run is a full scan, and later runs are maintained asynchronously for nodes that declare explicit dependencies. Nodes whose dependencies cannot be inferred, which the guidance names as programmatic constraints in default mode, computed values, inherited fields and dynamic facets over computed values, fall back to broader revalidation, and beyond roughly one hundred thousand records that difference becomes visible. The rules that follow are simple and cheap to adopt. Declare dependencies on every programmatic constraint you write. Keep table-scope constraints to a countable few and justify each one. And measure a full validation against production volumes during performance testing, because that duration is your worst-case maintenance window, and it is far better learned in September than during a Saturday cutover.

History is a decision worth making explicitly, because it is what lets you answer a question about the past with evidence rather than recollection. You activate it by defining a history profile and binding it to tables in the model, choosing whether it covers the reference branch only or all branches. Storage is a set of common transaction tables plus a history table for each historised table, where every functional field gains a companion operation column, so a history table carries roughly twice the fields of its source. Operations fold within a transaction, so a create followed by an update lands as a create. Two practical notes. Enabling history does not backfill, so the day you switch it on is the beginning of your audit trail, which is a good argument for switching it on in the first sprint rather than the week before go-live. And on a customer master with real change velocity these tables grow steadily, so treat retention as database engineering from the outset: partition the history tables, plan archival, size for three years rather than three months, and confirm the retention and purge options available in your version.

Because persistence was rewritten in 6.0, your backup and recovery design has two components rather than one. The repository is the relational database, and the indexes are files on a filesystem. A database-only restore may leave you needing an index rebuild, and how long that takes at your volumes is a number nobody can tell you in advance. Test a full restore before go-live, time the index rebuild, and write both numbers into the recovery plan. And be clear internally that snapshots are not backups. A snapshot is a governance artefact living inside the same repository; it protects you from a bad merge, not from a corrupted database or a deleted volume.

Six numbers belong on one dashboard from the first day the hub is operational: validation duration, match run duration against its window, work item queue depth, history table growth rate, replica refresh duration, and index directory size. Every one of them moves gradually rather than failing suddenly, which is exactly why they want a trend line rather than only an alert threshold. Deploy the Insight add-on alongside them, and be precise about the division of labour: Insight profiles the data itself against quality dimensions such as completeness and accuracy and turns them into dashboards a data owner will actually look at, while the six numbers above are the platform's operational health. Both matter, and they answer different questions.

14. Sequencing, and how to spend the first ninety days

The first fortnight is for decisions that are expensive to revisit, not for modelling. Lock the version at 6.2.3 and the runtime that implies. Lock the deployment shape and get the availability answer from ON EBX in writing with a version number on it. Archive the documentation set locally. Confirm the licence bundle covers what you need, noting that the enterprise bundle pairs the core platform with Match and Merge, Data Exchange and Insight, which is very close to the minimum viable set for a customer domain. And start the procurement conversation for the address verification service in week two rather than week twelve, because it is a contract, a security review and a network path, and it is the item on this plan most likely to be the thing everyone is waiting for in month four.

Weeks two to six belong to the model, and the acceptance criterion is not that the model is complete but that it is decided: person and organisation separated, source party and crosswalk tables designed, persistence mode chosen table by table with a written reason, the permission matrix of role against region against field sensitivity agreed with the business, and the survivorship fields identified even if the rules are not yet set. In parallel, load one source system end to end and reconcile it. One source loaded, counted and signed off teaches you more about your data than four weeks of workshops, and it de-risks the ingestion design while there is still time to change it. Use the import simulation and its error report as the gate before every real load, and make the reconciliation report a signed deliverable rather than a slide.

Weeks six to twelve are where the programme earns or loses its credibility, and the work is the labelled set, the decision tree, and the trust ranking. Build and adjudicate the labelled set as section 9 describes. Develop the matching policy against a subset of fewer than fifty thousand records, publish the scorecard, and iterate the tree with the data owner in the room. Run the trust ranking workshop and produce the field-by-field document, including where the steward outranks the source systems and where they do not. Compute the steward capacity number from your actual suspect rate and compare it honestly to the headcount you have been promised. If the two do not meet, say so in that month rather than in the month after go-live, because at that point the only remaining lever is the threshold and moving it is a quality decision disguised as a staffing one.

The last stretch before go-live is publication contracts, the restricted replica projection and its change-data-capture path, and the performance work that has to happen at real volume: a full validation, a full match run, a full replica refresh, a database restore with index rebuild, and a rehearsed unmerge. Then adopt the go-live posture I would argue for in every case. Start with automatic merge switched off. Run for the first weeks with everything above the threshold routed to a steward, which gives you a live measurement of precision against real inbound data rather than against your labelled sample, and then enable automatic merge rule by rule as each one demonstrates it has earned the trust. It costs a few weeks of extra steward effort. It buys you the ability to say, with evidence, that the hub has never wrongly merged two people, and that sentence is worth more to the programme than any feature you could ship in those weeks.

15. Design checklist

These are the decisions I would take to a steering committee on an EBX customer programme, in roughly the order they need answering. Most of them are not platform questions at all. They are choices about how the reference architecture fits your organisation, and every one of them is cheaper to make in design than to discover in test.

16. The eight things we would insist on

First, model source records and a crosswalk on day one. Because you design the model rather than inherit one, you can make lineage exactly what your domain needs, and a golden record you can trace back to the system that asserted each value is the foundation everything else in the hub rests on.

Second, persist survivorship results into real fields and keep computed fields for display. Computed values are resolved at read time, so they are neither historised nor replicated; persisting the result is what makes the golden record publishable to the warehouse, provable as at a past date, and fast to validate.

Third, rank the steward's decision at the top of the trust order unless there is a written reason not to, and give every exception a named owner and a sentence of justification. Stewards who see their judgement preserved engage with the hub, and that engagement is the entire return on a stewardship function.

Fourth, build the labelled golden set before you tune anything, and treat a single false merge in it as a release blocker rather than a percentage. Publish precision, recall and suspect rate every time the rules change. A match configuration whose accuracy nobody can state is not a configuration, it is a hope.

Fifth, contract the enrichment service in week two. Every platform in this category integrates one rather than building it, standardised input is what makes matching perform, and the procurement, security review and network path together take longer than any modelling task on the plan.

Sixth, treat model republication as a data migration event, as the product itself recommends. Semantic-mode evolution is intentionally flexible, which puts the migration plan in your hands: rehearse against production volumes, reconcile counts either side, and grant no exemptions for changes that redefine a key.

Seventh, decide the publication architecture during design rather than during integration testing. Replicate on commit into a deliberately restricted projection, let the change-data-capture tooling you already run publish from it, and remember that access to the replica is governed by the database rather than by the engine.

Eighth, go live with automatic merge switched off and earn it rule by rule. A few extra weeks of steward adjudication buys the ability to say, with evidence rather than assertion, that the hub has never wrongly fused two people. On a customer domain that sentence is the whole point.

EBX rewards teams who lean into what it is: a model-driven governance platform with an unusually strong permission and workflow story, wrapped around a matcher that is deterministic, configurable and fully explainable. Play to that and you get a customer hub the business can change without a release train, that a steward actually wants to work in, and whose every merge decision can be justified line by line. The design work that surrounds it, enrichment upstream and publication downstream and a labelled set to prove the match, is the same work every serious customer MDM programme does on any platform, and all of it is far cheaper to plan than to retrofit. If you are standing up a customer domain on EBX, or you have one that is technically live and not yet fully trusted, we are happy to talk it through.