Semantic Control Plane

The Architecture: Migration Mapping Created With Semantic Control Plane   

Core insight:  ArcXA's migration mapping layer bridges  semantic understanding lacking gap with: Informatica, Fivetran, Altran, and Collibra which are execution engines and passive catalogs. They know what happens (jobs run, data moves, tables get created) but they don't know why or what happens next. They

1. Extracting lineage from ETL metadata into a unified semantic model
2. Converting that lineage into SPO triples that encode both data flow AND semantic meaning
3. Inferring missing relationships via KGNN (knowledge graph neural networks)
4. Enabling bidirectional governance — policies defined in the control plane automatically propagate back to ETL tools

---

Layer-by-Layer Integration

Layer 1: Physical ETL & Execution Planes

Each platform exposes metadata differently:

• Informatica: PowerCenter repositories (Java-based, XML DAGs, mapping metadata via REST API). ArcXA connects to the repository to extract source→target column mappings, transformation logic, session configs.
• Fivetran: JSON connectors config + state metadata. Lightweight; ArcXA reads connector definitions to reverse-engineer pipeline DAGs.
• Altran: ETL engine logs + DAG definitions (typically XML or proprietary format). Requires parser-per-dialect.
• Collibra: Already a catalog—but a passive one. Stores business glossary terms, ownership, lineage declarations (often manual), classifications. Doesn't enforce them.

The problem: Each tool has its own schema, its own lineage model, its own classification taxonomy. No unified view. Cross-tool impact analysis (e.g., "if we retire this Oracle table, what Informatica jobs break?") requires manual detective work.

---

Layer 2: Migration Mapping & Lineage Extraction (ArcXA's Core)

This is where semantic translation happens. ArcXA reads each platform's metadata and converts it into normalized SPO triples:

Example 1: Informatica column mapping

Concrete ETL Tool Integration Patterns

Informatica → ArcXA:

• ArcXA connects to PowerCenter repository via SOAP/REST
• Extracts: mappings, transformations, session configs, source→target metadata
• Converts each mapping to SPO: (informatica_object_id, has_property, value)
• Collects transformation logic: (source_col, transformed_by, expression_id)
• Tracks: what gets deployed where (Informatica workflow version control)
• Bidirectional: when policy changes (e.g., new masking rule), ArcXA can auto-update mappings and redeploy

Fivetran → ArcXA:

• Fivetran API exposes connector definitions (JSON config)
• ArcXA parses: source connector type, target warehouse, column selection, transformation rules
• Triples: (fivetran_connector_id, ingests, source.table), (fivetran_connector_id, lands_to, target.schema.table)
• Adds inferred triples: sync frequency → SLA, connector health → data freshness risk
• Lightweight: Fivetran is config-driven, minimal lineage to extract

Collibra → ArcXA:

• Collibra is already a metadata hub—but underutilized for ETL
• ArcXA reads Collibra's glossary terms, classifications, custom attributes
• Problem: Collibra lineage is often manual or incomplete. ArcXA enriches it.
• ArcXA triples reference Collibra asset IDs: (collibra_asset_123, classified_as, ???)
• Bidirectional: ArcXA writes enriched classifications, lineage back to Collibra via API

Altran → ArcXA:

• Altran (Alteryx, or similar ETL engine) exposes workflows as JSON/XML DAGs
• ArcXA parses: input tools, transformations, output tools
• Triples: tool sequence, data flow, formula complexity
• Challenge: Altran transformations are opaque (visual designer). ArcXA uses heuristics: table join → infers key relationships, formula parsing for column mappings

_________________________________________________________________________________

Why This Creates a "Control Plane"

Passive catalog (Collibra):

• "Here's what exists and who owns it"
• Change impacts are discovered after the fact
• Policies are aspirational (documented but not enforced)

Active control plane (ArcXA + SPO):

• "Here's what exists, who depends on it, and what happens if you touch it"
• Change impacts are predicted before deployment
• Policies are enforced by the system (gates deployments, auto-updates downstream)
• Bidirectional: governance → execution (policies auto-propagate to Informatica, Fivetran, Altran jobs)

The triple store is the semantic glue. It connects:

• Execution (what Informatica/Fivetran actually do)
• Governance (what Collibra declares)
• Intent (what policies say should happen)
• Reality (lineage, data quality, freshness)

All queryable, all inferrable, all actionable in real time.

___________________________________________________________________________

The Migration Mapping Angle

For legacy migration (Oracle → IBM Power-native, DB2 → Snowflake), this becomes critical:

Migration wave: 100 tables, 50 Informatica mappings, 12 Fivetran connectors

Phase 1: ArcXA migration mapping extracts full lineage from current state
  → Builds triple store of all dependencies, data lineages, classifications

Phase 2: Plan cutover
  → What if we retire these 15 Oracle tables?
  → Which Informatica mappings touch them? (query triple store in 100ms)
  → Which Fivetran connectors? (1.2s query with impact chain)
  → What Collibra assets depend downstream? (full graph traversal)
  → What compliance rules? (policy engine checks all inherited classifications)

Phase 3: Execute migration
  → Informatica jobs auto-updated to read from new targets (policy engine writes new configs)
  → Fivetran connectors reconfigured to new source endpoints
  → Data quality gates enforced on new targets
  → Collibra updated with new lineage, automatically

Phase 4: Post-migration validation
  → Triple store shows: old vs new lineage side-by-side
  → KGNN compares: are the semantics equivalent?
  → Reports: "100% of column mappings preserved, 3 quality rules need tuning"