Enterprise AI Integration: Connecting AI to Legacy Systems

Why Legacy Integration Is the Hardest Part of Enterprise AI

Enterprise AI projects routinely fail not because of bad models or wrong algorithms, but because of the data plumbing underneath. Most large enterprises run on systems built in the 1990s or early 2000s — mainframes, SAP R/3, Oracle EBS, bespoke on-premise applications — that were designed for transactional processing, not data sharing.

These systems hold the data that makes enterprise AI valuable: decades of transaction records, customer histories, operational data, quality records, financial ledgers. But accessing that data for AI is rarely simple. Common challenges include:

Common Legacy Architecture Types

Different legacy systems require different integration approaches. Understanding the architecture type is the first step to planning the integration correctly.

Mainframe Systems (IBM z/OS)

Still in use at most large banks, insurers, and government departments. Mainframes process millions of transactions per day with extraordinary reliability. Data is stored in VSAM files or Db2 for z/OS. Integration options include:

• IBM MQ (message queuing) for event-driven data extraction without impacting mainframe performance
• JDBC/ODBC connections to Db2 for z/OS for direct database queries (read-only, non-peak hours)
• z/OS Connect EE for REST API exposure of CICS and IMS programs
• Offline data replication via tape or file transfer to cloud data warehouse

SAP ERP (R/3, S/4HANA, ECC)

SAP is the backbone of operations for most large UK and European enterprises. SAP exposes data through several mechanisms:

• OData APIs: Modern, REST-like APIs available in SAP S/4HANA for reading and writing SAP data — the recommended approach for new integrations
• RFC/BAPI: Remote Function Calls and Business Application Programming Interfaces — the classic SAP integration mechanism, complex but widely supported
• IDOCs: SAP's native document format for bulk data exchange — best for large batch transfers
• SAP Integration Suite (formerly SAP Cloud Platform Integration): SAP's own iPaaS, optimised for SAP-to-SAP and SAP-to-cloud integrations
• Direct Db2/HANA access: Read-only access to the underlying database — fast but bypasses SAP's authorisation model (use with extreme caution)

On-Premise Relational Databases (Oracle, SQL Server, PostgreSQL)

The most common legacy data store in mid-market enterprises. Integration is generally more straightforward than mainframe or SAP, but data quality and access control remain challenges. Standard approaches: Change Data Capture (CDC) using Debezium, read replicas for AI workloads without impacting production, and ETL pipelines to a cloud data warehouse.

Integration Patterns: Choosing the Right Approach

Data Quality Requirements for AI

AI models are only as good as the data they are trained on and the data they receive at inference time. Legacy systems often have significant data quality problems that must be resolved before AI can work reliably. Use this checklist to assess and remediate data quality before committing to a use case.

Integration Tools and Platforms

Case Study: Manufacturing Company Integrates AI with Legacy ERP

A UK-based precision components manufacturer with £180M annual revenue wanted to implement AI-driven demand forecasting and predictive maintenance. Their IT landscape was typical of an established manufacturer: SAP ERP (ECC 6.0) running on-premise, a 12-year-old Wonderware SCADA system for production monitoring, and a separate Oracle database for quality management.

The Integration Challenge

The AI system needed three data inputs: historical sales orders and inventory from SAP, machine sensor data from SCADA, and quality inspection records from Oracle. None of these systems talked to each other. The SCADA system had no API and exported data only via CSV on a manual basis. The SAP system used RFC-based interfaces. The Oracle database was accessible but contained 14 years of inconsistently formatted quality data.

The Integration Architecture

Results

The Key Lesson: Integration Architecture First, Model Second

In the manufacturing case study above, the model development itself took 6 weeks. The integration architecture design, data quality remediation, and pipeline build took 18 weeks. This ratio is typical. For any enterprise AI project involving legacy systems, plan your integration architecture and data quality programme first — before any model development begins.

The critical code below illustrates a simple pattern for exposing SAP BAPI data via a REST API wrapper — the first step in building an API layer on top of legacy systems:

# FastAPI wrapper exposing SAP BAPI data as a REST endpoint
# Sits between AI inference service and on-premise SAP system

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import pyrfc # SAP RFC Python connector
import logging

app = FastAPI(title="SAP Integration Layer")

# SAP connection config (loaded from secure vault in production)
SAP_CONFIG = {
 "ashost": "sap-prod.internal.company.com",
 "sysnr": "00",
 "client": "100",
 "user": "AI_SERVICE_USER",
 "passwd": "***", # Use Azure Key Vault / AWS Secrets Manager
 "lang": "EN"
}

class InventoryRequest(BaseModel):
 material_number: str
 plant: str

@app.get("/api/v1/inventory/{material_number}")
async def get_inventory(material_number: str, plant: str = "1000"):
 """Fetch current stock level from SAP via BAPI_MATERIAL_STOCK_REQ_LIST"""
 try:
 with pyrfc.Connection(**SAP_CONFIG) as conn:
 result = conn.call(
 "BAPI_MATERIAL_STOCK_REQ_LIST",
 MATERIAL=material_number,
 PLANT=plant
 )
 # Extract unrestricted stock from result
 stock = next(
 (r for r in result.get("STOCKREQLIST", [])
 if r["REC_TYPE"] == "BS"), # BS = unrestricted stock
 None
 )
 return {
 "material": material_number,
 "plant": plant,
 "unrestricted_qty": float(stock["QTY_UNRESTR"]) if stock else 0.0,
 "unit": stock["UNIT"] if stock else "EA"
 }
 except pyrfc.RFCError as e:
 logging.error(f"SAP RFC error: {e}")
 raise HTTPException(status_code=502, detail="SAP connection error")
 except Exception as e:
 logging.error(f"Unexpected error: {e}")
 raise HTTPException(status_code=500, detail="Internal error")

Related Articles