7 part series
A six-part series on IBM's own answer to the MAS 9 native-analytics ceiling: watsonx.data's open Iceberg lakehouse, fit-for-purpose query engines, MIF/Kafka extraction, medallion architecture, watsonx.ai and RAG, closed-loop write-back, and an honest head-to-head with Databricks.
MAS 9 native analytics has a real ceiling. This post names it, then makes the honest IBM-native case for watsonx.data — open Apache Iceberg, fit-for-purpose engines, and a bridge to watsonx.ai your MAS AI Service license already opened.
The three IBM-sanctioned ways to move Maximo data into watsonx.data — MIF REST/JSON over OSLC, the Kafka source connector, and MAS 9.1's asynchronous bulk export — plus the Cloud Pak for Data fabric and the SaaS constraint that decides which ones you can actually use.
How Apache Iceberg's ACID transactions, schema evolution, and time-travel snapshots map onto a Bronze/Silver/Gold medallion for Maximo EAM data — with the full Db2 CREATE DATALAKE TABLE syntax, named conformed entities, and the registration mechanics that keep it all in sync.
How watsonx.data routes interactive SQL, ETL/ML, and high-concurrency BI to different engines — Presto, Presto C++/Velox, Spark, Db2 Warehouse, Netezza — over a single Iceberg copy, with the coordinator/worker architecture, IBM's price/performance claims vs Photon, and the RU cost model.
How the Maximo Iceberg lakehouse stops being a reporting layer: custom PdM/RUL models on watsonx.ai, AutoAI for RAG, the Milvus/OpenSearch/OpenRAG stack over maintenance manuals and work-order text, Granite and Llama model routing, and three concrete ways to write AI outputs back into Maximo.
The series finale: a caveated head-to-head — Iceberg vs. Delta, Presto C++/Velox vs. Photon, IBM Knowledge Catalog vs. Unity Catalog, Milvus/OpenRAG vs. Databricks vector search — plus how IKC and Apache Ranger govern Maximo-derived data, LABTRANS PII masking, and watsonx.governance lineage.
