Functional view: make sense of your spaghetti application

Without naming conventions, an IBM i application quickly becomes unreadable: a plate of spaghetti where you can no longer tell where one strand begins and another ends. The functional view in DISCOVER rebuilds the map: from your code, your metadata and the links between components, it infers the functional breakdown, names it, and makes it navigable for far more people than developers alone.

Stop drawing this map yourself. Point to your application, then ask for component detection and AI-based node naming. On large applications, the tool works in the background while you move on to something else.

Two mechanisms work together. Drawing on the ARCAD metadata repository, Louvain algorithms cluster components according to their interactions and form functional groups; AI then reworks the naming to make it accessible. Algorithms bring the rigor, AI brings the readability.

The result is a multi-level tree: a parent (say, order and customer management) has its children, which in turn have their own. For each group, you see the number of components, their type and a detailed view of what it contains.

Naming is derived from component descriptions, widely used on IBM i: an order file and its related programs produce a title such as “order management”. The breakdown itself relies on analyzing the links between components: weight, interactions and type. A program that updates a file doesn’t carry the same weight as one that simply reads it, and that distinction feeds into every level.

Nothing is set in stone, though. AI doesn’t always match the way you want to see things, so rename a node, group things differently, add comments or new children.

Once the map is built, you can read it in two directions. Start from the highest level (the entire application) and drill down, or start from a single component and work your way up to everything around it.

Three starting points are available:

As you go deeper, a mini-map shows where you are. Hover over a node to reveal its contents, check incoming and outgoing links, trace the path back from the main menu, and scroll to zoom out for a wider view.

Ask the question: “if I change this component, what gets impacted?”. The tool returns every element concerned in a diagram that is more concise than a conventional impact analysis, each one placed in its functional context.

A developer-level analysis works program by program; here, the view is functional. Change a simple CL program and you immediately see that it affects order and customer management, right down to order creation. To find your way around: solid lines for a direct connection, dotted circles for the zone of influence.

The map isn’t only there to help you understand; it also helps you clean up. An isolated component that doesn’t operate with the others may well have no place in the application scope, so take it out.

Conversely, an incomplete group often points to a missing component. A file should be linked to orders or customers, yet the link doesn’t appear: dig a little and you find the program sitting unnoticed in a developer’s library, off to one side. Move the source back where it belongs, run the analysis again, and the file reconnects to its context.

Where there was only a technical tangle, readable mainly by seasoned specialists, the functional view brings out a living, accessible functional map: built automatically, navigable and open to correction. Above all, this knowledge is no longer the preserve of a select few: developers, analysts and modernization leads can all reach it in language they understand.

Diagrams can be saved and folded into your documentation. And the approach holds up at scale: one of our customers runs DISCOVER on an application of some 92,000 components, relationships included.