IBM i Impact Analysis: Scope It Before You Quote

“We just need to extend the customer number.” Who would commit to a deadline based on that one sentence?

That’s often how a change on IBM i begins: a short request from the business, landing on the CIO’s desk with a deadline already in mind.

In this article, I focus on the exact moment when you have to commit. Three familiar requests run through it: changing a VAT rate, extending a customer number, and opening a function to the web. Each time, the requirement is the same: explain the scope, show what justifies it, and bring together the people who own the decision.

The word “just” describes the request. It says nothing about its consequences. A single field can run through orders, invoices, and exchanges with other applications.

Take a concrete example. Finance wants to raise a VAT rate from 10% to 12%. You find the rate table, and the change looks trivial. Then a question comes up: if last month’s invoice is reprinted, does it keep its original amount? What about the matching credit note? It all depends on the business rules actually being executed: what the application stores, what it recalculates, and when.

On IBM i, applications carry years, often decades, of business decisions. That wealth is a major asset, but a hard one to tap into:

The result: one dependency surfaces, then another, and the estimate drifts. So ask yourself: when would you rather discover a dependency before the quote, or after you’ve committed?

This is exactly the need DISCOVER addresses: making what’s affected visible before the commitment is locked in. For the CIO, the value is immediate: concrete evidence to justify budget and timelines, and fewer blind spots.

DISCOVER works like a geographic map of your application portfolio. Anyone can look at a map, get their bearings, and find what concerns them. You view it at country scale to grasp the big picture, then zoom in on a region, a city, a street. The map stays the same; only the level of detail changes.

Applied to an IBM i application, this metaphor changes the nature of scoping meetings:

Everyone looks at the same map. You follow a lead, step back, and adjust the view to the question at hand. Decision-makers take part without reading a single line of RPG, while experts keep all the technical depth they need.

Moving between levels is seamless. At the top, the functional map shows the main domains (customer management, item management, settings…) and, in red, how they interact. At the intermediate level, component diagrams and the data model reveal files, programs, and links. At the finest level, the code diagram exposes a program’s logic. A local question always fits back into the wider portfolio, with a clear path back to the technical details.

Even when a repository already exists, this experience makes the difference. Information takes on new value when a team can explore it, challenge it, and agree on what it shows.

Filter the procedure repository on VAT: DISCOVER surfaces the procedure that retrieves the rate, linked to its module, its service program, and every program that calls it. The technical name hardly matters. What counts is the relationship it reveals: several processes rely on the same point, and the CIO finally sees why the analysis reaches beyond the original component.

Data lineage completes the picture. Starting from the order detail file, a screen field, or a report, you can see where each value comes from and where it goes, calculation by calculation, all the way back to the original business rule. For the finance department, the stakes are clear: knowing which calculations and uses to review before changing the rule.

This time, the request is blocking: 99,999 customers, the 5-digit limit has been reached, and the sales team can no longer create new customers. DISCOVER starts from the CUSTOMER file and its identifier, follows the relationships to history and orders, then on to the linked components. The scope takes shape.

Not everything that’s linked will necessarily change. Impacted components are grouped into families (data, access, processing, interfaces, SQL), and the team qualifies each impact: modify, check, or test. That’s the foundation for a well-argued estimate and a clear division of work.

A 5250 screen is often the entry point to a process that validates data, assigns an identifier, and feeds other processes. Where is the duplicate check? Which process approves the creation? DISCOVER pinpoints that logic. You can then decide what to reuse (for example by exposing it as a web service) before building the modern interface.

A map is only valuable if it’s accurate. To base decisions on it, you need to know what it’s built on. This is where DISCOVER stands apart: its relationships are computed, not guessed.

The repository is built by analyzing IBM i sources and objects. Every relationship displayed comes from that analysis, never from assumption. This delivers four guarantees:

In practice, the same question always gets the same answer. No language model reinterprets the map each time it’s consulted. That’s essential when you commit a budget, justify a timeline to management, or split up checks across a team: everyone needs to find tomorrow what they saw today.

AI certainly has its place in DISCOVER, but in a clearly defined role. When the assistant receives a natural language question, it translates it; it doesn’t make up the answer. The paths it displays come straight from the computed repository. Likewise, the functional map combines a deterministic algorithm (the Louvain method, which detects groups of tightly connected elements) with AI to name those groups. As for generated documentation, it’s a solid starting point that human review turns into a trusted reference.

AI models are advancing fast, and large language models have been released at a sharply accelerating pace in 2026. These capabilities should be put to work: LLMs help analyze, propose, and deliver faster.

But this acceleration shifts the bottleneck. If a change can be proposed in minutes, the real question becomes: how does the team understand its consequences for the application? The CIO, the business, and the experts must still be able to examine the scope, follow a dependency, and discuss what needs to be preserved. The more changes you produce, the more you need to understand and validate them together.

That’s why the faster AI moves, the more indispensable specialized studios like DISCOVER will become. A general-purpose conversational assistant answers one question at a time, in a linear way. A specialized studio offers what a conversation can’t:

My conviction comes down to one sentence: the faster we can act, the more it pays to make our understanding of the system explicit and shareable. Let’s harness the power of AI and give the team the map it needs to stay in control of the effects.

How many of your projects start with: “Who knows this part of the application?” In four common situations, understanding the application portfolio determines when work can actually begin.

The benefit is measurable: in scoping time, in the number of dependencies uncovered before estimating, or in how easily a colleague can pick up an analysis.

And the roadmap goes beyond IBM i: cross-references with Java and other systems, support for external databases (PostgreSQL, Oracle, MySQL…) and, eventually, a planned extension to IBM Z mainframes running z/OS. The goal: one common map for increasingly hybrid applications.

“We just need to extend the customer number.” With DISCOVER, your first response changes: ask to see the related data and affected processes, bring the right people together around the same map, and agree on the checks before you commit.