Thanks Curt. In our case I think our domains are different enough, and would likely be managed by different groups, so that having separate tenants seemed like a convenient way to keep things separated and present a simpler view for our end users. But I imagine we could probably accomplish the same type of separation for users by leveraging RBAC and metadata security.
Original Message:
Sent: 03-12-2024 12:22
From: Curt Pearlman
Subject: Accessing data from another tenant
Generally there is a per tenant license. Every customer is deployed with a "Base Package" that consists of a trio of tenants: dev, test and prod. Then, as needed for special circumstances, additional tenants can be licensed and this is done quite regularly as some customers wish to have add'l dev tenants, and/or add'l test tenants. In the case of managing Product and Customer let's say in separate tenants, likely a Base Package for each would be appropriate since each will likely need to be supported from a dev, test and prod perspective.
All of that said, if the customer can comfortably manage from an administrative perspective (development schedules, roadmaps, etc..) both domains in the same Base Package set of tenants, then I think most would agree that at the end of the day, it is a simpler approach than splitting them across separate Base Packages. Both options are there, but again, simpler to not introduce the additional technology if not needed. That's just a basic tenet (notice different spelling :-) of life and data management!
------------------------------
Curt Pearlman
Original Message:
Sent: 03-12-2024 12:10
From: Tim Magney
Subject: Accessing data from another tenant
Is there per tenant license required when setting up multiple tenants, i.e. a Customer tenant and a Product tenant? Or is the licensing based on the total number of profiles across all tenants?
------------------------------
Tim Magney
The Greenbrier Companies
Lake Oswego OR
Original Message:
Sent: 03-11-2024 14:22
From: Curt Pearlman
Subject: Accessing data from another tenant
Is there any additional Storage space required on the replicated tenant is based on only the keys required for cross linking or does it replicate all core attributes for that domain( e.g. – customer domain – customer profile, address, relationships etc)?
For any domain which uses DTSS to replicate records from one tenant to another, those records will occupy space on the target tenant and as such, will be counted as licensable profiles within the target tenant as well as within the source tenant. So yes they will be counted twice. But this makes sense because they require storage in both tenants and consume compute in both tenants.
Any special licensing required for using DTSS or does basic Reltio Tenants( in this case Customer and Product tenants) cover this licensing.
The DTSS technology is free of charge.
Since one tenant's data is replicated to another tenant – does it require any separate licensing based on the best of breed/ golden records count?
See answer to #1.
Data residency / sovereignty requirements specially on Customer sensitive data attributes.
Not sure what you're asking. Pls be specific.
Do we consider any special measure like data dirtiness, data redundancy, data conflicts etc due to this replication.
Not sure what you're asking. Pls be specific.
If a customer have many subject areas to be mastered (e.g. Customer, Product, Supplier, Material), is it advisable to have many tenants? Is there any POV?
The POV, and really the original driver of the DTSS technology is that oftentimes different organizations within a firm will be responsible for different domains. As such, organizationA is likely to have a roadmap and development schedule for the domain it manages different than organizationB that has its own roadmap and development schedule for the domain it manages. And so to enable each organization to operate freely and in a manner decoupled from the other, each would have its own tenant to control, but the records from those tenants can be shared with other tenants via DTSS.
If DTSS is being used, in the integration layer (ETL / DI tool) what type of configuration are required?
DTSS does not rely on or need any support from an external tool such as an ETL. It is a technology within Reltio that synchronizes profiles across tenants using batch and real-time modes of operation as configured within the DTSS configuration JSON. So lastly, do know that there is no UI for DTSS configuration. You must edit a JSON file.
Lastly, when designing and configuring use of DTSS, it is advisable to engage with Reltio PS to ensure best practices and experience are brought to bear.
------------------------------
Curt Pearlman
Original Message:
Sent: 03-11-2024 13:54
From: Abhijit Auddy
Subject: Accessing data from another tenant
Thanks Curt for your response.
Few more questions on data tenant.
- Is there any additional Storage space required on the replicated tenant is based on only the keys required for cross linking or does it replicate all core attributes for that domain( e.g. – customer domain – customer profile, address, relationships etc)?
- Any special licensing required for using DTSS or does basic Reltio Tenants( in this case Customer and Product tenants) cover this licensing
- Since one tenant's data is replicated to another tenant – does it require any separate licensing based on the best of breed/ golden records count?
- Data residency / sovereignty requirements specially on Customer sensitive data attributes.
- Do we consider any special measure like data dirtiness, data redundancy, data conflicts etc due to this replication.
- If a customer have many subject areas to be mastered (e.g. Customer, Product, Supplier, Material), is it advisable to have many tenants? Is there any POV?
- If DTSS is being used, in the integration layer (ETL / DI tool) what type of configuration are required?
Thanks & Regards,
Abhijit Auddy
AIA-MDM
Phone - +91 6292127385 / 9804392131
VNET : 333221
Original Message:
Sent: 3/8/2024 10:56:00 AM
From: Curt Pearlman
Subject: RE: Accessing data from another tenant
The Reltio architecture supported this idea from day one, empowering entity types to be allocated across tenants, but able to reference each other as you say. The relevant technology for this is DTSS (Data Tenant Subscription Service), but more accurately it could've been called ITSS or Inter-Tenant Subscription Service. In your case you would configure DTSS to replicate the customer records from the Customer tenant into the Product tenant. DTSS sets up each of them within the Product tenant to have and maintain a crosswalk that refers back to its master Customer record managed within the Customer tenant. Updates made to the master Customer records automatically propagate to their counterparts held within the Product tenant.
Hope that helps.
------------------------------
Curt Pearlman
Original Message:
Sent: 03-07-2024 08:30
From: Abhijit Auddy
Subject: Accessing data from another tenant
If I configure Customer in one Reltio tenant and Product in another tenant, is there any way to link them? I want to create a Product->Customer relationship in Product tenant .
------------------------------
Abhijit Auddy
Cognizant
------------------------------