feat: rebuild evidence-first application workflow

This commit is contained in:
2026-07-27 17:56:15 +02:00
parent c24892f381
commit fe5f24704f
57 changed files with 3815 additions and 3555 deletions
+12 -12
View File
@@ -1,7 +1,7 @@
# Significance Research: Swisscom — Staff Data, Analytics & AI Engineer
> Use in cover letters and summaries — NOT in resume bullet text.
> Provides field context demonstrating awareness of the data engineering landscape.
> Optional context only. Reverify every market/company statement from a current primary source before use.
> Never convert company scale, industry trends or likely benefits into Dennis's personal impact.
---
@@ -9,24 +9,24 @@
**The problem:** Legacy enterprise data warehouses (Teradata, Oracle) are expensive to scale, inflexible for modern analytics workloads, and difficult to integrate with ML pipelines. The industry-wide shift to cloud-native data platforms (AWS, Azure, GCP) is driven by cost, elasticity, and the rise of the data lakehouse pattern.
**Competing approaches:** Most enterprises face a choice between lift-and-shift (rehosting on cloud VMs — minimal benefit), re-platforming (moving to managed services like Redshift), or full re-architecture to a lakehouse (S3 + Athena/Iceberg + Glue). The lakehouse pattern (Apache Iceberg on S3 + Athena) is increasingly the de facto standard for cost-efficient, ACID-compliant analytics at scale.
**Architecture context:** Enterprise migrations may involve rehosting, re-platforming or re-architecture. Use this only to explain the technical choices in a verified job-specific context; do not assert a universal standard.
**Why this matters:** Swisscom serves millions of Swiss customers across mobile, broadband, and enterprise — the data volume is significant. Moving Fulfillment data pipelines to a cloud-native architecture directly affects the speed and cost of analytics for business-critical processes.
**Why this matters:** Fulfillment pipelines are business-critical. No personal data-volume, cost-saving or speed-improvement metric is currently verified.
**Differentiation:** Dennis didn't just configure existing pipelines in a new environment — he introduced Apache Iceberg (open table format with time-travel and schema evolution), AWS Glue Tables as the catalog, and CloudFormation for IaC provisioning. This reflects current best practices in data lakehouse architecture, not a basic ETL migration.
**Candidate-specific evidence:** Dennis used Iceberg, AWS Glue/Athena and CloudFormation while migrating pipelines in his owned domains. Do not claim he selected these technologies for Swisscom or introduced them company-wide unless separately verified.
**Field overview: Data Lakehouse Architecture (20242026)**
The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS) with the ACID guarantees and query performance of data warehouses — has become the dominant architecture for new data platform builds. Apache Iceberg has emerged as the leading open table format, supported by AWS (Athena, Glue), Databricks (as Delta Lake alternative), and Snowflake. Engineers who have implemented Iceberg in production (not just read about it) are in high demand as organizations migrate off proprietary DWH systems.
Open table formats such as Apache Iceberg are relevant context for lakehouse roles. Reverify any market-share or "dominant architecture" statement from current primary sources before using it in a cover letter. Context must never be converted into a claim about Dennis's personal system scale or architecture authority.
---
### SW-2: Component Ownership at Scale — Field Context
**The problem:** In large data engineering teams at enterprise companies, the "Component Owner" model is how organizations assign accountability for production systems. Unlike a ticket-based dev model, Component Owners are responsible for a system's full lifecycle: reliability, compliance, SLA, on-call, and stakeholder communication. This is a Staff-engineer-level responsibility.
**The evidence:** At Swisscom, Dennis's Component Owner role covers production operation, data quality, governance, incidents and on-call obligations for Fulfillment ETL pipelines. Describe those verified responsibilities directly; do not use a generic title-equivalence claim.
**Why this matters:** Swisscom's Fulfillment domain carries business-critical data — provisioning, activating, and tracking customer service orders for Switzerland's largest telecom. Pipeline failures in this domain directly impact customer experience and revenue.
**Why this matters:** Swisscom's Fulfillment domain carries business-critical operational data. Avoid claiming a quantified customer or revenue effect without evidence.
**Differentiation:** Dennis holds this responsibility as a Staff Engineer (Engineer IV) — the same person building the pipelines is accountable for their reliability in production. This is the "full-stack data engineer" model that platform teams increasingly demand.
**Candidate-specific value:** Dennis combines implementation with production accountability for his components. That is the defensible distinction; broader market-demand claims require fresh sourcing.
---
@@ -34,7 +34,7 @@ The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS
**The problem:** Data pipelines have traditionally been deployed on bare metal or VMs, leading to environment inconsistency, difficult scaling, and slow deployments. The shift to Kubernetes for data workloads (not just web services) reflects the maturation of the data platform discipline.
**Industry trend:** Running data applications (Airflow, Spark, custom Python pipelines) on Kubernetes is now standard practice at mature data organizations. GitLab CI/CD with Kubernetes deployment is the Swiss/European enterprise standard (as opposed to GitHub Actions + AWS ECS in US-heavy startups).
**Industry context:** Kubernetes and CI/CD are recognizable production-delivery signals. Do not claim a regional or industry standard without current sourcing.
**Differentiation:** Swisscom's use of Kubernetes for Python data applications confirms production-grade container orchestration for data workloads — not just a dev/test environment.
@@ -44,8 +44,8 @@ The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS
The data engineering discipline has undergone a significant shift in the past 3 years:
1. **From batch to streaming:** Kafka-based event-driven architectures have replaced many nightly batch processes
2. **From proprietary DWH to open lakehouse:** Teradata/Oracle S3 + Athena/Iceberg is the dominant migration pattern
2. **From proprietary DWH to open lakehouse:** Dennis has direct experience moving owned-domain pipelines from Teradata/Oracle processing to S3 + Athena/Iceberg within a wider programme
3. **From manual to automated infra:** CloudFormation, Terraform, and Pulumi have made IaC standard for data platform teams
4. **From separated to embedded ML:** Data engineers who can own the ML data layer (not just supply data to a separate ML team) are increasingly valuable
Dennis's current stack (Kafka, PySpark, AWS S3/Glue/Athena/Iceberg, Kubernetes, GitLab CI/CD, CloudFormation) maps precisely to this modern paradigm.
Dennis's current stack includes Kafka, PySpark, AWS S3/Glue/Athena/Iceberg, Kubernetes, GitLab CI/CD and CloudFormation. Use the named evidence; avoid generic claims that it maps "precisely" to every target platform.