What IBM i Teams Need as Everything Around the System Changes.
Retirement, outsourcing, modernization and AI are creating different futures for IBM i teams. The same hidden requirement sits underneath every path forward.
The application is still doing its job. The difficult conversation is about what happens next.
An experienced developer is planning retirement, and the replacement role is still open. An external maintenance partner is one option. Modernization is another. AI may help, but nobody wants faster answers to create more work for the people already carrying the system.
Hiring changes who does the work. Outsourcing changes who provides the service. Modernization changes the technology. None removes the need to make the application’s logic, dependencies and business rules explicit, verifiable and reusable.
The knowledge behind the code
Take a familiar question: “Where is the customer discount calculated, and why do credit notes round differently?”
Finding the pricing program is only the beginning. The answer may also depend on how the batch is run, which file or member is actually used, and what happened in that specific execution. In one illustrative IBM i example, an RPG program may reference one file while a CL program redirects it with OVRDBF. Looking at the program alone would miss part of the story.
Then there is the business reason. Code may show what happens, but not always why. A finance agreement or an exception known only to an experienced developer may explain the behavior.
This is why application knowledge is difficult to hand over. Fortra’s 2026 IBM i Marketplace Survey found that 69% of respondents ranked IBM i skills among their top planning concerns, while 73% ran applications developed in-house. Platform expertise helps, but it does not automatically bring the history of a specific application.
The next person needs these pieces together. Otherwise, the same question becomes another investigation, another interruption and another change that needs rechecking.
An explanation the next person can use
This is the role of a trusted application context layer: connecting application logic, data, business rules, dependencies and evidence so teams and AI tools can uncover what matters, reduce avoidable rework and escalation, and move from questions to actionable outcomes more efficiently, with access and data boundaries under enterprise control.
For the discount example, the useful result is more than an answer. It brings together the calculation, the batch setup, the confirmed credit-note exception and the relevant source versions. Open questions remain visible. The expert adds the business reason once; others can return to the same explanation instead of rebuilding the story.
Ozgar is one example of this approach. Its living knowledge hub connects plain-language explanations, diagrams, business logic and supporting sources across complex, long-running applications, so people and compatible AI tools can reuse the same application context. Ozgar builds on Specific-Group’s enterprise software experience since 1998.
The same context can support onboarding, handover, change requests, incident analysis, AI-assisted work, maintenance, modernization and knowledge continuity.
Teams do not need to wait for a retirement, outsourcing decision or transformation project. They can start with the application questions already consuming time today.
Give context your whole team can reuse
AI assistants need application-specific context too. But more context is not necessarily better context. Copied routines, outdated documentation and irrelevant objects can add noise and consume AI capacity, while a rarely used month-end path may contain exactly the logic a task needs.
What matters is finding and ranking the right context for the question. Ozgar combines searches by meaning, relationships and exact text to surface relevant application knowledge while keeping explanations connected to supporting sources. Engineers can explore the logic behind an answer, while compatible AI tools and agents can use the same maintained context through APIs, plugins, IDE extensions and configured MCP connections.
That reuse becomes increasingly important as AI adoption grows. If several team members ask similar questions, the application should not need to be rediscovered each time. When a question is refined, the next prompt should not need to rebuild the investigation from the codebase. Application knowledge should accumulate, not reset with every person, prompt or tool.
A fast answer can still become expensive when teams must find missing context, correct results, repeat prompts or escalate the same exceptions to senior experts. The real cost includes both AI usage and human rework, regardless of whether the team uses IBM Bob, Claude Code or another assistant.
Ozgar’s Hidden Cost Calculator provides an input-based starting estimate for exploring some of these less-visible costs.
Make application knowledge part of what you maintain
If application knowledge matters, maintain it like the application itself. Keep it current as the system changes, connect business rules to the code and data behind them, and make the supporting evidence easy to verify.
That becomes even more important as business processes increasingly extend beyond a single technology. IBM i may remain at the core while Java services, APIs, databases or other platforms become part of the surrounding landscape. Teams need a way to preserve a clear view of how that application knowledge fits together as the environment evolves.
Control matters too. Organizations should know where their application knowledge is stored, which people and tools can access it, and what information may leave the enterprise. A context layer should strengthen existing systems and workflows, not require a refactor or team reorganization.
The goal is not to document one question at a time. With application sources ingested, teams can investigate difficult questions with a system-level view, uncover relevant dependencies, trace the evidence back to source, and reuse that understanding across change requests, incidents, onboarding and AI-assisted work.
People change. Tools change. Systems evolve. What the organization has already learned about its application should not need to be rediscovered.
Request an IBM i walkthrough. Bring one application question your team keeps having to explain.