AI and ML are reshaping how developers design, build, and improve modern software applications. For many businesses with IBM i workloads, however, the conversation tends to start with some apprehension, questioning whether it is possible to adopt AI technology without completely replatforming their IT systems.
By Joydip Kanjilal
There are no technical barriers that prevent IBM i from accessing or benefiting from AI. This can be accomplished by leveraging pragmatic IT integration patterns that build on the existing systems rather than replacing them.
The AI Opportunity for IBM i Shops
In this section, we’ll examine why this is a compelling time for IBM i businesses to investigate artificial intelligence. Two main reasons explain why many AI projects struggle to achieve their goals. First off, there is access to high-quality data that can be relied upon for modeling. The other is having a truly accurate understanding of what adopting AI will entail, i.e., once we rule out the prevailing assumption that we need to move everything to the cloud.
Why IBM i is rich with structured business data
Many organizations with detailed, modern workloads running on the IBM i platform are often challenged by the AI conversation because they expect it to be held on a different AI platform and believe that combining AI with the IBM i platform implies a complete abandonment of the platform.
This assumption is completely wrong, and acting on it can lead to costly mistakes and other negative consequences. However, what is being missed by most people having the conversation about AI and IBM i is this: The data currently stored in the IBM i environment of most organizations is among the cleanest, most structured, and most operationally relevant data in their enterprise.
The IBM i platform has been developed for decades with a focus on maintaining transaction integrity, and the data stored on the IBM i incorporates decades' worth of embedded business logic into the database's logical schema.
Common misconceptions about complete cloud migration
One of the biggest myths about AI is that you need a total migration to the cloud before you can really take advantage of AI. You can call an AI service from an IBM i system without moving any tables out of production.
You use an AI service, like other services in your application, as a service that you call. You don't have to move IBM i to the cloud for it to participate in any AI services. It should be noted that your IBM i system need not be an AI platform; instead, all you need is that it should be able to utilize AI workflows.
Security and Governance Considerations
In this section, we’ll examine the security and governance considerations you should be aware of when connecting to external AI services.
Safeguarding Sensitive IBM i Information
The IBM i platform has one of the most robust security models available, and the integration of Artificial Intelligence (AI) within this environment must not become a weak link in its overall security.
Before any data is sent to an AI service, access to the data is controlled by IBM i object-level authorities, which, in turn, determine which programs and profiles are granted access to the data within the IBM i environment and send it to AI.
If a program requires temporary access to an object, using an adopted authority such as USRPRF(*Owner) will grant that access only when the program is executing, rather than granting standing authority to the underlying files to end users.
Db2 for i has an option for Row and Column Access Control (RCAC), which will restrict or mask sensitive columns of data (such as personal identifiers or financial information) to ensure that only the minimum amount of data is included in an API call when the data is sent to an external AI service.
RCAC enforces this at the database level, so masking applies regardless of which programming interface (e.g., RPG, SQL, or Python) is used to construct the API call.
API Authentication and Encryption
Whenever IBM i makes a call to an external AI service, it must use TLS — there are no exceptions for "internal" traffic over local networks or VPN connections. You should NEVER hard-code your credentials or API Keys into your RPG or Python scripts; you must always store them (securely) and retrieve them when needed at runtime. It should also be noted that a short-lived token is often preferred because it is more secure than a long-lived one.
Audit and Compliance Considerations
You should be aware of the compliance obligations if you want to send business data to an external AI service. These obligations can be GDPR or any other industry-specific rules.
Three areas must be agreed upon and documented properly: where the data is processed and stored; whether the service provider utilizes your data as part of the training of their model; and whether you will be able to produce an audit trail of when the data was sent, what the data looked like, and why the data was sent.
The IBM i platform has a unique advantage in this regard because it incorporates QAUDJRN (a Security Audit Journal) that can capture object access and authority events related to the AI integration, and allows the application to create its own audit entries in Db2 for each outbound call.
Governance cannot be an after-the-fact box to check; it must be part of the design of the API and AI services, since the design will dictate whether data sent from the IBM i can be audited and whether it is sufficient to ensure compliance with all regulatory requirements outlined above.
Use Cases
The key use cases include the following:
Forecasting Demand via Order History
Consider a distributor has an extensive amount of past order history data stored inside Db2 for i - typically spread across an order header, order detail, and item master tables.
Every evening, a nightly CL (an acronym for Control Language) program scheduled through the IBM i job scheduler runs SQL to pull and aggregate the history based on demand for that product, such as order volume, purchasing trends, lead time, etc. That information is sent to a Demand Forecasting Model.
A component then sends the feature set to the forecasting model. This can either be an RPG service program issuing the HTTP call from SQL, or a Python script in PASE using requests, a popular open-source Python library for making HTTP calls.
The Demand Forecasting Model generates a forecast, which is then written back to a Db2 results table, i.e., the forecast results table. The next morning, the application reads this table and provides reorder recommendations to the buyers.
Detecting Anomalies in Transaction Data
The ability to detect anomalies in transaction data is one of the critical advantages AI can provide. Let us understand how this entire process works.
When transactions are posted to Db2 for i, an automated job will score them against a model that recognizes normal transactions and identify any transactions that are outside of normal for investigation. Such transactions may include unusual order values, atypical order timing, or any suspicious account activity.
This can take place in near real time by executing an RPG application that calls REST services in response to transaction updates, or in micro-batches by executing a Python job to score transactions periodically.
Integrating AI into an IBM i Workflow
In this section, we’ll examine the possible options you have for AI adoption within an IBM i environment.
Using REST APIs to interact with external AI services
The easiest way to integrate an external AI service is to call it as a REST API over HTTPS. All AI providers will accept a JSON-formatted request, process it according to their model's inference or behavior, and return a JSON-formatted response to the caller.
Making outbound HTTP calls has been supported by the IBM i platform for many years. RPG can also connect to external AI platforms via two approaches: using relational SQL-based HTTP_POST scalar functions as defined in Db2 for i, or by using an open-source HTTP API library.
The following code snippet shows how you can read product data from an API.
SELECT SYSTOOLS.HTTPGETCLOB(
'https://api.example.com/v1/products/' ||
TRIM(CHAR(:product_id)),
'<httpHeader>
<header name="Accept" value="application/json"/>
<header name="Authorization" value="Bearer ' || :token ||
'"/>
</httpHeader>'
) AS RESPONSE
FROM SYSIBM.SYSDUMMY1;
Figure 1 below demonstrates a high-level overview of how an RPG program can call an external API:
Figure 1
Figure 1 illustrates how an RPG Program communicates with an external AI Service via an API layer. The RPG program residing on the IBM i environment acts as the system of record. It builds a request from Db2 for i data and passes it to either an SQL HTTP function or an open-source HTTP client, both of which then send it to an external AI service over HTTPS.
Next, the AI Service performs model inference and returns a JSON response over the same connection. The RPG program will then parse this response and write the results back to Db2. So, the whole communication process begins and ends on IBM i, with the cloud service simply facilitating the communication.
Integration Layer Using Python in PASE
Support for PASE (Portable Application Solutions Environment) enables IBM i developers to leverage Python's capabilities on the IBM i platform. PASE is an AIX-like runtime environment that allows you to run AIX executable code directly on IBM i, which means you can use the open-source Python runtime directly on IBM i.
You no longer need to leave your IBM i platform to use the full Python ecosystem. By integrating AI workflows into a single application, developers can create AI-enabled solutions that enhance their customers' businesses.
IBM i developers who wish to work with Python via PASE can connect to a Db2 database from within their IBM i environment using libraries such as ibm_db or ODBC, perform data manipulation and modeling, consume RESTful APIs using libraries such as requests, and run small machine learning models locally when necessary.
Hybrid Approach
A hybrid model is the preferred model for most businesses. While the core functionality of the IBM i platform resides on the IBM i platform, the model training and inference modules execute as external services.
The design of an application, as well as the processes by which it runs, dictates when and how AI will be used; IBM i will be the system that contains the orchestration logic and the source-of-record data. When an application calls upon AI, it sends only the relevant (minimized) data to a cloud-based service via a REST API.
The service will then return the result to the application running on the IBM i platform over the same HTTPS connection. By taking this hybrid approach, business logic remains on the IBM i environment, and customers do not have to execute substantial workloads on Power systems. Using a hybrid approach keeps business logic on the IBM i platform and prevents customers from having to run heavy workloads on Power hardware.
Working with Db2 for i Data
If you’re working with IBM i, your data will reside in Db2 for i. In this section, we’ll examine the key considerations you should keep in mind when working with your data residing in a typical IBM i platform.
Extracting and Preparing Data
Db2 for i is a mature database with a mature set of SQL capabilities. You can write set-based SQL to create the feature set you need (aggregates, joins, windowed calculations over time, etc.) and let the Db2 optimizer do the hard work rather than have to read records one at a time through legacy interfaces.
Securing API exposure
IBM i allows RPG or SQL programs to be exposed as RESTful web services using its Integrated Web Services (IWS). One approach can be to expose your RPG programs or SQL as REST endpoints natively. Another approach can be to use a lightweight Python framework running in PASE. Whatever your approach, remember that an endpoint should return only the necessary fields, not any additional ones.
Data transformation considerations
Traditional character representation for IBM i (EBCDIC) is incompatible with AI services and JSON (UTF-8), so a conversion is necessary to avoid corrupted characters and data quality problems. If the ibm_db driver is configured correctly, it will perform the conversion for you, but you must also ensure it is configured appropriately.
The other consideration is that you should be careful when handling issues such as date formats, decimal precision, and NULL values when normalizing data across multiple tables and storing it in JSON format for an AI service to consume.
Takeaways
- When talking about AI, most people tend to see the IBM i platform as an obstacle or a legacy system that separates an organization from the future.
- The integration patterns described earlier exhibit a very different conclusion – IBM i is not a limitation on an organization's overall AI strategy; rather, it is an AI data engine.
- The historical accumulation of incredibly clean, well-structured, and validated business data over decades is precisely what AI models desperately need to deliver value to organizations.
- IBM i has an extremely robust security model, excellent levels of transactional integrity, and unparalleled operational reliability.
- While the intelligence derived from AI may come from the cloud as a service, the source of irreplaceable value will always be the enterprise data that resides on the IBM i platform today.
- Rather, the winners will be those that understand the value of their existing systems, connect their data to modern technology through interfaces such as Python and REST, and turn decades of enterprise data into a long-term competitive advantage.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online