MIF vs. OSLC vs. REST API vs. Kafka: Choosing the Right Maximo Integration Surface in 2026

The Maximo integration framework has always been the platform's superpower. It is also the place where most performance incidents and most "we should have built that differently" regret originates. The reason is the same now as it was in 2012: the framework has four first-class integration surfaces (MIF, OSLC, the JSON REST API, and Apache Kafka), each with its own strengths, its own scaling profile, and its own failure modes. Picking the right one for the job is the difference between an integration you never think about and one that wakes you up at 2 a.m.

The 2026 version of this question is sharper than the 2020 version, for two reasons. First, the MIF/JMS path is being de-emphasized in favor of Kafka for outbound and REST for inbound. Second, the API-key authentication model has become the default for machine-to-machine traffic, replacing basic auth on SOAP and REST endpoints.

This article walks through each surface, when to use it, and what the May 2026 performance data is telling us.

The four surfaces, in one table

MIF / JMS: still alive, but increasingly legacy

The Maximo Integration Framework (MIF) with JMS queues was the original enterprise integration surface, and it is still the path of least resistance for many legacy ERP, EAM, and CIS integrations. Publish channels and Enterprise Services are mature, well-documented, and supported. Object structures, message sequencing, error handling, and the continuous-queue mechanism are all in place.

The honest limitations in 2026:

• One consumer per queue. The JMS path in MIF does not parallelize the way Kafka does. If you need to process 5,000 events per minute, MIF/JMS will bottleneck on a single consumer.
• Basic auth is the default. Most 7.6 deployments still authenticate MIF endpoints with basic auth, which is a problem in any zero-trust network posture. API keys (issued in the Administration Work Center) are the recommended replacement and have been since MAS 8.x.
• Operational complexity. JMS queues on WebSphere or WebLogic are a separate operational surface. MIF/Kafka consolidates the message broker into the MAS deployment, which is a meaningful simplification.

The 2026 rule of thumb: MIF/JMS for the legacy integration that already works and that you cannot economically rewrite. For new work, look at MIF/Kafka or the REST API.

MIF / Kafka: the new default for high-volume outbound

The MIF Kafka path is the natural evolution of MIF for outbound event streams. Kafka is a managed dependency in MAS 9.x; the MIF framework publishes JSON messages to a Kafka topic, and your external consumer (or App Connect) subscribes.

The performance wiki at ibm-mas.github.io has the most useful published data on MIF/Kafka behavior. The headline results from the lab runs:

• TPS scales linearly with the number of CRON JVMs and Kafka topic partitions. Doubling both doubles the throughput.
• There is a distribution penalty at high parallelism. With more partitions, the variance in processing time grows (from 2% at 2 partitions to 10% at 12 partitions in the lab). For a given throughput target, fewer partitions with more CRON JVMs is more even.
• The 1-consumer-per-partition rule applies. You cannot get more parallelism than partitions, and you cannot have more consumers than partitions on a single topic.
• For small messages (e.g., 10 assets per message), more partitions help. For large messages, fewer partitions with more CRON JVMs is better.
• Best practice: one Kafka topic with 6 partitions, and parallel processing across multiple topics if you need to scale beyond that.

The 2026 best practice, in plain language:

• Use MIF/Kafka for outbound event streams of any meaningful volume (>100 TPS sustained).
• Configure 6 partitions per topic as a starting point.
• Run at least 2 MEA (Maximo Enterprise Adapter) JVMs to consume, more as TPS grows.
• Treat the topic names as part of your integration contract — they are the API.

The JSON REST API: the right answer for most new work

The Maximo JSON REST API exposes business objects as resources and uses the same object structure machinery under the hood. For modern inbound and outbound integrations, it is the recommended default. The reasons are simple:

• API key authentication is built in. Generate an API key in the Administration Work Center, attach it to a security group, and the integration is authenticated without basic auth or session management.
• Stateless and scalable. Each call is independent. MEA pods can scale horizontally; load balancers route.
• The same MIF object structures back the API. You can develop a MIF object structure (with all of its processing rules, validations, and field mappings) and then expose it through the API without duplicating logic.
• Documentation is consistent across IBM Maximo Manage, Health, and Predict. A team that learns the JSON API for one application can apply it to others.

The honest limitations:

• Synchronous by default. A REST call that triggers a long-running MIF processing chain holds the HTTP connection open. For long operations, use the async pattern (publish an event, return 202, process out-of-band).
• Bulk operations are still tricky. If you need to ingest 50,000 records, the REST API is the wrong tool. MIF/Kafka (outbound) or a MIF file-based Enterprise Service (inbound) is the right tool.
• Rate limiting is in your hands. The MAS deployment does not rate-limit the REST API for you. If your integration is bursty, you need a client-side rate limiter.

OSLC: still useful, narrow audience

OSLC (Open Services for Lifecycle Collaboration) is the standard that IBM helped develop for lifecycle integration. In Maximo, the OSLC surface is used to:

• Provide UI integration points (the "Launch in Context" pattern that lets a record in one system open the right context in another).
• Expose change-request-like resources for integration with ALM tools.
• Support the legacy /oslc API path (which has been substantially superseded by the JSON REST API at /api).

The 2026 honest read: if you have an existing OSLC integration that works, leave it alone. For new work, the JSON REST API covers almost all of the use cases that OSLC was used for, and the JSON API is what the new documentation and tooling targets.

SSO, OIDC, and the security surface

Two changes in 2026 worth highlighting on the authentication front:

• OIDC is now a first-class option for SSO in MAS 9.x, alongside SAML 2.0 and LDAP. OIDC is the right answer for integrations with modern IDPs (Okta, Azure AD/Entra ID, Auth0, IBM Verify) and is the path with the best tooling support for token refresh and short-lived credentials.
• Multiple identity providers of the same type are supported. If you have multiple OIDC providers (e.g., one for employees, one for contractors), you can configure both. This used to be a hard limitation in earlier MAS versions.

For the integration surface itself, API keys remain the default for machine-to-machine traffic. OIDC is the right choice when the integration is acting on behalf of a user (e.g., a portal that needs to act as the logged-in user, not as a service account).

App Connect: the iPaaS layer

App Connect is IBM's iPaaS and is a licensed add-on to MAS. It is the right answer for:

• SaaS-to-Maximo flows (Salesforce, Workday, ServiceNow, SAP S/4HANA Cloud).
• Event-driven orchestration where you need a visual flow designer and a managed runtime.
• Health and Predict – Utilities data loads. The IBM Maximo labs documentation specifically calls out App Connect as the supported path for loading meter data and asset types into Health and Predict – Utilities when you don't want to write custom MIF integrations.

App Connect is not a replacement for MIF or the REST API. It is a layer on top of them, and its value is the catalog of pre-built connectors and the visual flow editor. The trade-off is AppPoints (it's an add-on) and a per-flow runtime that adds latency compared to a direct MIF/Kafka path.

A decision tree for picking the right surface

Given a new integration requirement, the 2026 decision tree is:

1. Is the source a SaaS app that has a pre-built App Connect connector, and the volume is moderate (<100 TPS)? Use App Connect. Don't reinvent the connector.
2. Is the source a stream of events at meaningful volume (>100 TPS sustained)? Use MIF/Kafka outbound. The consumer can be your own service, App Connect, or another Kafka-native system.
3. Is the source a synchronous caller (REST client, portal, Mobile app) and the response needs to be returned in the same request? Use the JSON REST API with API key auth.
4. Is this a legacy MIF/JMS integration that already works and that the business does not want to touch? Leave it on JMS. Plan to migrate when you do the next major upgrade.
5. Is this an ALM/lifecycle tool that expects OSLC? Use OSLC.

A worked example: ERP inventory sync

A typical 2026 question: "we need to sync inventory items and balances between Maximo and SAP S/4HANA, in near real time, with about 5,000 events per business hour."

• MIF/Kafka outbound for the high-volume event stream. Configure one topic with 6 partitions. Two MEA JVMs consume.
• JSON REST API inbound for the SAP → Maximo side (creating new items, updating vendor information).
• App Connect is an alternative if the team does not have the MIF/Kafka operational expertise, but the latency is higher.

The wrong answer: trying to do this on MIF/JMS. The 1-consumer-per-queue limit will throttle the throughput, and basic auth on the JMS endpoint is a security audit finding waiting to happen.

The 2026 hygiene checklist

For any team running MIF integrations in 2026, the minimum hygiene bar is:

• API keys for everything new. No basic auth on MIF endpoints, period.
• Object structures are versioned. When you change an object structure, you do not break existing consumers. Use a new object structure or a clearly versioned interface.
• JMS queues are monitored. For any legacy MIF/JMS integration, watch the queue depth, the consumer health, and the error queue. The MIF framework's error queue is the most common silent failure mode.
• Kafka topic naming is a contract. Document the topic names, the message schema, and the ownership. Treat them like a public API.
• OIDC for user-context integrations. Use API keys for service-to-service; use OIDC for "act as this user."
• The MIF performance wiki is your friend. The ibm-mas.github.io/mas-performance wiki has the lab data, the test methodology, and the scaling patterns. Read it before you commit to a topology.

The Maximo integration story in 2026 is a mature one. The surfaces are well-defined, the performance data is published, and the operational patterns are well-trodden. The work is picking the right surface and operating it with discipline.