Hybrid data governance across a bank with 14 business units
A bank has Db2 z/OS on-premises (1.2 PB), Oracle Exadata on-premises (300 TB), and an Amazon S3 data lake (80 TB). IBM Cloud Pak for Data 4.8 runs on OpenShift in AWS us-east-1. Fourteen business units need one catalog, column-level lineage, dynamic masking for PII, and GDPR subject access requests within 72 hours. Data Virtualization connects to on-premises over a 200 Mbps Direct Connect with 35 ms round-trip latency. There are 900 catalog users and 60 stewards. The bank wants to avoid copying on-premises data to the cloud, but a proof of concept shows a join between virtualized Db2 z/OS and S3 taking 90 seconds for 1 million rows. The CISO wants masking enforced in CP4D; the mainframe team refuses schema changes. Budget favors a single CP4D instance. What governance architecture do you recommend?
1. Decide where to virtualize, where to replicate, and where to mask. Justify the trade-offs with performance and control.
Read the worked answer
Do not use Data Virtualization for every join. The 90-second result for 1 million rows is consistent with a 200 Mbps link and 35 ms latency plus z/OS processing; virtualization adds value for low-volume, selective lookups and for giving stewards a single query surface, not for repeated large joins. Virtualize reference data, customer-key lookups, and subject-access queries that filter to one person. Replicate or curate high-volume joined datasets into the S3 lake or a CP4D-managed zone through an ETL/CDC pipeline, then catalog the curated copy. Mask at the point that matches control: for on-premises PII exposed through virtualization, use CP4D data protection rules and masked views so the mainframe schema stays unchanged; for replicated data, mask before landing in the lake so raw PII never enters the broad-access zone. Keep unmasked PII in a restricted project with separate access. Validate that the chosen masking method is supported for Db2 z/OS virtualization; if not, project only non-sensitive columns and join to a tokenized lookup.
2. How would you meet the 72-hour GDPR subject access request with this architecture?
Read the worked answer
Treat the 72-hour requirement as a process and lineage problem, not a full-database scan. Use the catalog and column-level lineage to identify which systems and columns hold identifiers for the data subject. Predefine SAR query templates in Data Virtualization that filter by customer ID or token and return only the subject's records, avoiding broad joins. For high-volume systems, use the replicated curated zone where lineage is known and queries are faster. Route requests through a steward workflow with approval, execution, review, and audit logging. Mask non-essential PII in the response and record who accessed what. Test the end-to-end clock with a synthetic subject across z/OS, Oracle, and S3; if any source cannot return within the window, pre-extract that source into a governed SAR store. The catalog provides discoverability and evidence, but the SLA depends on prebuilt queries and tested ownership.
3. What are the risks of a single CP4D instance for 14 business units, and what minimal split would you propose?
Read the worked answer
A single instance reduces cost and gives one catalog, but it creates a shared blast radius: one failed upgrade, quota exhaustion, or IAM misconfiguration affects all business units. Metadata can also leak across catalogs if governance is loose. The minimal split is not 14 instances. Separate production from non-production into different clusters or at least different OpenShift clusters with separate upgrade windows. Inside production, keep one CP4D instance, but use separate projects, catalogs, resource quotas, and network policies per business unit, and restrict platform administrators. For the most sensitive function, such as a CISO-owned PII zone, consider a separate instance or cluster with separate encryption keys if auditors require administrative separation. Document which controls are logical versus physical; do not claim project-level isolation is equivalent to separate clusters.