01 A little introduction
Rujikorn Ngoensaard
Senior Data Engineer
I build and operate
enterprise data platforms.
Where I started
Bachelor’s in Electrical and Electronic Engineering,
Ubon Ratchathani University, 2013–2017.
Outside of work
02 The journey
An evolving practice across manufacturing, commerce and enterprise data.
2013–2017 · The foundation
Electrical and Electronic Engineering
Ubon Ratchathani University
Nov 2017–May 2020
Process Engineer, Engineer I
Developed diagnostic and repair-routing automation for HDD testing. Operated scripts across 130+ Linux VMs and coordinated technical repair and retest work.
May 2020–Dec 2021
Product Design Engineer
Promoted from Senior to Staff Engineer
Automated reporting and centralized data workflows with Airflow. Redesigned ML prediction services for HDD testers.
Jan 2022–Jan 2023
Data Engineer
Built personalization pipelines, search and product-discovery services. Selected website placements recorded more than 50% relative improvement in click-through rate.
Feb 2023–Jul 2024
Data Engineering Specialist
Delivered AWS lakehouse pipelines for 150+ sources within assigned domains. Built governance foundations and enabled experiment tracking through a private MLflow deployment.
Oct 2024–Present
Senior Data Engineer
Build and operate enterprise data platforms across integration, analytics, governance and production support. Lead technical delivery with three outsourced engineers and design target architecture with infrastructure and security stakeholders.
03 Selected work
Senior Data Engineer
October 2024–Present
I build and operate enterprise data platforms across integration, analytics, governance and production support. I lead technical delivery with three outsourced engineers, setting priorities, reviewing solutions and coordinating incident response.
Reconstructed lineage and moved Tableau analytics to Microsoft Fabric and Power BI. Delivered in three months.
Automating daily access updates around business approvals, legacy-compatible outputs and protected employee-data processing.
Defined target governance and workload boundaries for an Azure/Fabric tenant transition. Assessment and transition preparation continue.
Build and validate pipelines from SAP FI/RE, Salesforce, databases, APIs and files with ADF, Databricks and ADLS Gen2.
Developed naming, metadata, ownership and lifecycle standards, plus Databricks access controls. Adoption in progress.
Investigate Fabric throttling and integration-runtime bandwidth to guide capacity and scheduling decisions; coordinate incidents and vendor follow-up.
Analytics Migration Central Pattana
I led the migration from Tableau to Microsoft Fabric and Power BI, reconstructing dashboard-to-source lineage and coordinating technical delivery.
Delivered scope
Three months.
Data dictionaries and business specifications were missing, with no clear source contact or owner. I manually reconstructed dashboard-to-source lineage to establish the dependencies.
I led technical delivery and coordinated with existing Airflow workflows and Infrastructure under compute and scheduling constraints.
Direct source-database access was restricted for this migration. Source delivery used data files plus accompanying metadata files for file-level validation.
Source delivery
ADF
Zero records Skip
Skip all remaining downstream tasks for that batch.
Nonempty batch Databricks
Check row counts and columns against the accompanying metadata.
Power BI results must match the equivalent Tableau report for the same reporting period.
RLS Automation Central Pattana
The challenge was replacing laptop-dependent Excel macros while preserving established access rules, business authority and downstream compatibility. I moved daily Power BI access processing to scheduled Azure Data Factory and Databricks workflows, rolled out in July 2026.
Engineering owner for the master RLS pipeline and dashboard distribution.
Current organisation data identifies who exists; approved assignments and business review determine access. I separated these inputs and imported review decisions before rebuilding the review queue. Unresolved groups stay in review while daily processing continues; completed assignments leave the next queue. This keeps organisational changes subject to established access rules and business decisions.
No.A reviewed No is a decision; blank is not approval. Regular users can inherit their existing organisation group’s approved assignment.
Azure Data Factory orchestrates the automated processing.
Inputs
Current organisation data
Prior approved assignments
Automated · Databricks
Registry processing
Published access outputs
SharePoint workbooks
Microsoft Fabric datasets
From registry processing
New-group review queue
Business decision
Review workbook assignments
Back to registry processing
Reviewed assignments
on a subsequent run
Groups absent from the approved baseline enter the review queue. Unresolved groups keep blank review fields and effective access of No. Daily processing continues.
Fabric Lakehouse supplies current organisation and user data. SharePoint supplies the prior approved master and business review workbook; lookup and dashboard configuration define access attributes and distribution.
Bronze, Silver and Gold processing produces a master workbook with Group, User and Special User sheets, one new-group review workbook, 12 domain-specific dashboard workbooks and ReportRLS datasets for configured Fabric destinations. Regular-user records carry 13 business-rule-driven access attributes.
Dashboard outputs are fresh .xlsx files; generation does not run VBA or require existing macro-enabled workbooks. Monthly workbook naming does not change the daily processing cadence.
Acceptance concerns approved legacy macro outputs and business rules: sheet structures, headers, column order, assignments, all 13 regular-user attributes, required blanks and dashboard mappings.
Special users retain approved exception assignments and values. They do not inherit regular organisation-group assignments or have the 13 regular-user attributes recalculated. They are appended to regular users without deduplicating by email, preserving the required legacy behavior (UNION ALL).
Configured PII is encrypted before persistence in Databricks data. Deterministic hashes support identifier matching across protected datasets; Azure Key Vault protects encryption material. DEV and PRD use separate security configurations and key material.
Authorised export processing decrypts required PII. Excel outputs and configured Fabric destinations may contain decrypted information; logs must exclude plaintext employee data and secrets.
ADF orchestrates separate Databricks activities. Pipeline run identifiers connect processing and structured logs. Validation covers source structure, row counts, protected joins, assignments and output schemas.
Source, permission, processing and publishing errors surface as failures. Publishing handles locked SharePoint files. Setup and deployment operations are separate from daily processing; business reviewers retain access decisions and approval.
Target Architecture Central Pattana
The tenant transition called for clearer access governance across tenant boundaries, less unnecessary data duplication and alignment between cloud-foundation and data-workload responsibilities. I designed the Azure and Fabric target architecture with infrastructure and security stakeholders around those concerns.
| Design concern | My contribution |
|---|---|
| Tenant and governance boundaries | I assessed cross-tenant access, governance concerns and unnecessary data duplication, then defined target boundaries and transition dependencies with infrastructure and security stakeholders. The design is intended to clarify how access is governed and data is distributed across those boundaries, while informing the assessment and preparation needed for transition. |
| Shared foundation and platform responsibilities | I aligned hub-and-spoke responsibilities by distinguishing shared cloud-foundation duties from data-platform workload operations. With infrastructure and security stakeholders, I defined responsibility and workload boundaries to clarify who handles each area and where operational handoffs belong. This provides a shared basis for coordinating transition preparation across foundation and workload teams. |
| Domain ownership — Design direction | I defined a direction in which domains are accountable for the data they publish, while shared platform responsibilities and common governance controls remain explicit. This separates accountability for data assets from operation of the foundation and data platform, allowing domain ownership to coexist with shared controls as the design develops. |
Outputs: target architecture design; responsibility and workload-boundary definition; transition dependency assessment.
Target architecture defined and responsibilities aligned; assessment and transition preparation continue.