Skip to main content
Employer projectAir cargoPublic company

Lufthansa Industry Solutions

Lufthansa Cargo and aviation engineering work across rule curation, booking APIs, partner data exchange, delivery pipelines, and observability.

IT Consultant / Senior Full-Stack Engineer at Lufthansa Industry Solutions, 2022 - 2025

Lufthansa aviation platform modernization project visual
40%
MTTR reduction
4
Lufthansa workstreams
CI/CD
delivery and monitoring

Work overview

A quick read on where the work sat, what made it hard, what I owned, and what changed.

Context

This work covered several Lufthansa Industry Solutions assignments, including CurationEngine, SmartBookingAPI, Cargo EDI, and Centeract. CurationEngine was the rule-driven decision layer around smartBooking / Cargo Booking API, while EDI covered operational air-cargo messaging for shipment data, eAWB/eHouseManifest, PreCheck, acknowledgements, errors, and status flows.

What was hard

The hard part was separating fast-changing cargo-booking logic from stable backend APIs while keeping partner integrations and cargo message flows reliable. The work moved between rule artifacts, API integration, EDI shipment-data messages, Kubernetes deployments, CI/CD, and incident support.

My part

I worked as a fullstack/platform-oriented engineer: writing Spring and TypeScript code, integrating APIs, supporting Drools/KIE and Maven-based rule delivery, working through architecture reviews, deploying services, tightening monitoring, and troubleshooting production-adjacent issues.

What changed

The visible result was a cleaner delivery model for booking logic and less ambiguity around production support. The clearest measured impact I can name publicly is observability work that helped reduce MTTR by 40%.

Constraints that mattered

  • Several systems and teams touched the same cargo process, so interfaces and handovers had to stay understandable.
  • Rule changes affected booking behavior, so versioning, promotion, rollback, and testability mattered.
  • Business Central, KIE Server, Maven artifacts, containers, and API services all had to line up per environment.
  • Cargo, maintenance, and EDI work all use domain-specific language; vague documentation quickly becomes expensive.

Approach

01

Separate rules from API code

For CurationEngine, the useful platform idea was to keep volatile cargo-booking rules in managed Drools/KIE artifacts instead of burying every condition in Java application releases.

02

Make deployments repeatable

Rule artifacts, runtime containers, environment properties, service credentials, and CI/CD promotion needed predictable paths across development, test, staging, and production.

03

Keep support close to delivery

Logs, health checks, deployment diagnostics, and handover notes were treated as part of the work because rule-runtime failures can be hard to reason about after the fact.

Key decisions

A few engineering choices that shaped the implementation and delivery path.

Decision

Present the Lufthansa work as one aviation case study

Reason

The projects shared the same pattern: airline domain constraints, enterprise delivery, platform reliability, and production support.

Impact

The case study shows the connected scope without blurring the differences between API, rules, EDI, and assistance work.

Decision

Keep booking rules versioned and deployable

Reason

A rule change can alter customer-facing booking behavior without changing the core API code.

Impact

Business logic could move through controlled build, deployment, promotion, and rollback workflows.

Decision

Treat observability as part of the release

Reason

A deployed rule container or API integration without useful runtime signals pushes work into incident calls and manual investigation.

Impact

Monitoring and troubleshooting improvements contributed to a 40% MTTR reduction.

What I did

Built

  • Spring, TypeScript, and platform changes across aviation and cargo workflows.
  • Delivery support around Drools/KIE rule artifacts, runtime containers, and environment-specific configuration.
  • Frontend and tooling pieces for maintenance and release-management contexts.

Improved

  • Rule and service release paths through CI/CD, artifact handling, documentation, and handover.
  • Runtime visibility through logs, health checks, dashboards, and deployment diagnostics.
  • Deployment safety around Kubernetes-based services, rule runtimes, and operational handovers.

Owned

  • Technical consulting with Lufthansa teams and cross-functional stakeholders.
  • Troubleshooting across rule-runtime deployments, API integration, configuration, and production support paths.
  • Clear project documentation and handover notes for teams operating the systems.

Cargo booking rule-curation view

A sanitized view of how rule-managed cargo-booking decisions sat around the Booking API.

01

smartBooking API

Java/REST service sending offer and booking context and receiving curated booking decisions.

02

Curation Engine

Decisioning layer that turned shipment, route, product, and customer context into rule facts.

03

Cargo EDI

Operational messaging for eAWB, eHouseManifest, PreCheck, acknowledgements, errors, and status updates.

04

Drools / KIE Runtime

KIE Server containers executing deployed rule artifacts and returning decisions.

05

Delivery Platform

Business Central, Maven/KJAR artifacts, CI/CD, containers, configuration, logs, and rollback.

Learnings

  • Rule engines are only useful in production when artifact versioning, deployment, and rollback are handled like normal release work.
  • Cargo booking logic changes often enough that separating rules from core API code can reduce release pressure.
  • The most valuable documentation explains runtime boundaries, credentials, artifact versions, and support paths.