Back

Apprenticeship Logbook (Master 1)

Integrating an APS in an Industrial Environment: Feedback

Published on 15/10/2025

ArchitectureIndustryPythonTesting

[!NOTE] TL;DR: Integrating an Advanced Planning & Scheduling (APS) tool in a factory requires careful engineering. As part of my apprenticeship at Orange Business, I converted a monolithic extraction pipeline into a robust modular architecture: reducing code from 1543 lines to ~130 lines per orchestrator module, eliminating type errors (323 → 0), and securing operations with 716 automated tests.

Industry 4.0 is no longer an abstract concept. On the ground, I support major industrial groups in optimizing real-time production flows. My day-to-day role centers on bridging the gap between Information Technology (IT) and Operational Technology (OT).

This challenge is at its peak when deploying a unified Advanced Planning & Scheduling (APS) solution across multiple European factories.

Context: Custom Engineering over Off-the-Shelf ETL

Historically, the industrial client I work with operated in silos: fragmented systems, scattered data files, and manual processes. The strategic goal was to implement a centralized tool capable of breaking down these barriers and consolidating production data from every factory.

To feed this complex system, we needed to harvest and transform data from multiple sources (ERP systems, HR, floor equipment). While we could have chosen a commercial ETL tool, I advocated for a custom Python engine connected to secure staging tables. Why this structural choice?

  • Full Transparency: Essential for auditing data transformations and diagnosing anomalies (impossible with a “black box” ETL).
  • Testability: A custom engine allows unit testing every business rule independently.
  • Scalability: Decoupling source logic from target formats ensures that adding a new factory never breaks the global system.

To discover how I managed my lead role on this project, read my article on autonomy and collaboration.

Architectural Refactoring: Ending the 1543-Line Monolith

To meet tight deadlines for initial rollouts in Germany and Italy, an initial working version was shipped rapidly. Over time, however, this script accumulated compound technical debt: a monolithic file reaching 1543 lines.

Maintaining this setup jeopardized upcoming site rollouts. I proposed a full architectural refactor. Drawing on domain-driven models from the target system, I refactored the codebase into single-responsibility modules (configuration, data adapters, models, utilities). Result: the orchestrator module dropped to ~130 lines. Today, new features affect only specific modules, preventing unintended side effects.

flowchart TD
    ERP[(Central ERP)] <-->|REST API / JSON| APS{APS Engine<br/>PlanetTogether}
    APS -->|BOMs & Schedules| MES[MES System<br/>Shop Floor]
    MES -->|Production Feedback| APS
    
    subgraph Cloud [Cloud / Edge Infrastructure]
        APS
    end
    
    subgraph Factory [Factory - Local Network]
        MES
    end
    
    classDef db fill:#9333ea,stroke:#7e22ce,stroke-width:2px,color:#fff;
    classDef engine fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#fff;
    classDef factory fill:#16a34a,stroke:#15803d,stroke-width:2px,color:#fff;
    class ERP db;
    class APS engine;
    class MES factory;

Quality Assurance: 0 Pyright Errors & 716 Automated Tests

Architecture alone cannot guarantee production line stability. To achieve industrial-grade reliability, I led the refactoring with strict metrics:

  1. Typing & Static Analysis: The legacy codebase accumulated 323 Pyright errors. I established a strict “0 error” gate before any release.
  2. Comprehensive Test Suite: Leveraging the decoupled architecture, I implemented 688 unit tests and 28 integration tests automated in our GitLab CI pipeline. I targeted mission-critical rules, including a sync mechanism that previously overwrote manual scheduler edits silently.

This rigor, accelerated by my AI-assisted architecture workflow (detailed in my multi-model approach), turned production risks into reliability assets.

Key Takeaways

Technical Debt is a Choice

While accumulating debt to hit critical deadlines can be justified, delaying repayment creates exponential overhead. I learned that an engineering integrator ensures resilience not by dodging urgency, but by establishing a clear architectural doctrine (a lesson I began forming during my CI/CD work the previous year).