Engineering
From SAP Information Steward to AI: Why Ixia Builds Data Technology
Our habit of engineering our own tooling did not start with the AI cycle. It started when delivery kept hitting the same gaps.
A position Ixia has argued since 2014. This piece rewrites it for 2026.
Dave Welensky, Director · Published August 2026 · 4 min read
Ixia has been building data technology around delivery problems for over a decade: an enterprise reporting add-on for SAP Information Steward, control systems for external files, workflow acceleration for IDoc loads, operational data products. Ixia Data Quality AI is the same behaviour at platform scale.
A pattern older than the AI cycle
There is a pattern behind every piece of technology Ixia has built. A real delivery problem appears. The available tooling has a gap. We engineer the missing piece, deploy it on the programme that needed it, learn from how it behaves in production, and improve it. Then the next programme inherits it.
None of this began with the current AI wave. It began because consultants who also engineer get impatient with gaps that cost their clients time.
The Information Steward gap
SAP Information Steward is where many enterprises keep their data quality rules. The gap our delivery teams kept hitting was visibility: the rules and their failures lived inside the tool, and the business people who owned the data could not see trends across the enterprise without becoming Information Steward users themselves.
So we built BIWorx: an add-on that extracts rule results from the Information Steward repository using SAP Data Services, lands them in SQL Server, and serves business users an enterprise view of rules, failures and trends. No IS console required. The business could finally watch its own data quality move.
The same years produced quieter engineering with the same DNA: a control system that manages external files entering SAP Data Services landscapes and enforces governance before bad files become load failures, and a workflow pattern that parallelises large IDoc batches beyond standard limits because cutover windows do not negotiate. Both are documented in Ixia whitepapers. Neither was a product strategy. Both were delivery problems that deserved engineering.
From add-ons to a platform
Run that behaviour for a decade, across migrations, quality programmes, operational data products for retail, hospitality and programme management, and the accumulated learning wants a home. Ixia Data Quality AI is that home: profiling, business-defined rules, SAP-aware packs, duplicate detection, and AI where it genuinely carries load, in classification, matching and summarisation, with confidence scores a human reviews.
The AI parts are new. The judgement about what to build, what a data steward actually needs to see, which rules migrations really fail on, where a human must stay in the loop, is the part that took twenty years. That is why the platform behaves like it was built by people who deliver, because it was.
Why this matters to a buyer
A consultancy that ships software understands delivery differently. It has felt its own tooling break at volume, supported its own decisions in production, and learned the difference between a feature that demonstrates well and one that survives a cutover weekend. When we implement other vendors' platforms, that experience travels with us. When the tooling has a gap, we already know what we will do about it.
Key takeaways
- Ixia's build behaviour predates the AI cycle by a decade.
- BIWorx gave the business enterprise visibility of Information Steward rules and trends.
- The whitepapered engineering, file control and parallel IDoc workflows, came from cutover pressure, not product strategy.
- Ixia DQ AI is the accumulated delivery judgement, platformed.
Recognise your programme in this?
Written by the people who deliver the work. The conversation works the same way.