Core Problems You Are Likely Facing in an IBM i Environment

Lack of a clear understanding of the existing system

Most IBM i application landscapes have grown organically over decades and now consist of thousands of programs, files, and processing flows. In the absence of formal, reliable documentation, new developers often struggle to understand how modules interact and how data flows through the system. Critical knowledge is typically concentrated in the minds of a few long-tenured employees, and the true impact of changes is often only discovered after defects appear in production. 

As a result, onboarding new developers takes longer than necessary, misunderstandings about program behavior are common, and teams become increasingly dependent on tribal knowledge rather than documented facts.

High risk when making changes

In a mature IBM i system, even seemingly small changes can have far-reaching consequences. Modifying a database field or file layout can unexpectedly affect dozens of programs, while business rules embedded deep in the code remain invisible without extensive manual inspection. Because there is no reliable way to predict downstream impact, development teams are often forced to proceed cautiously and reactively. 

This leads to frequent break-fix cycles, higher defect rates in production releases, increased operational costs, and a general reluctance to make changes that could otherwise improve the system.

Scattered or outdated documentation

Many IBM i environments either lack documentation entirely or rely on documentation that has been manually created and is no longer up to date. Information is often spread across personal folders, shared drives, and internal wikis, with no consistent update process, resulting in fragmented, inconsistent views of the system. 

Teams waste valuable time searching for answers, risk acting on outdated or incorrect information, and struggle to transfer knowledge efficiently between developers, analysts, and support staff.

Complex technology mix

IBM i applications frequently combine multiple generations of technology, including different RPG variants, CL programs controlling batch processing, DDS-based and SQL-managed database objects, and ILE service programs with dynamic binding. Understanding how these technologies interact across language and architectural boundaries is extremely difficult to do manually. 

As a consequence, dependency analysis is often incomplete, hidden coupling between modules introduces subtle defects, and refactoring or modernization initiatives become far more challenging and risky than they need to be.

The Blueprint Functions

• Domain Segregation with Automated Suggestions

• Impact analysis and dependency mapping

• Application maps and visualization

• Business rule extraction and code quality assessment

• Application architecture understanding

• One-click "where used" and "are using" for impact analysis and cross-referencing

• Documentation publishing in the internal network

• Handles any combination of older architecture to modern technologies  

The Blueprint Documentation

• Automated documentation generation

• Diagrams included in the generated documentation

• Offline formats supported: PDF, SVG, and draw.io

• Web-based interactive format containing deeplinks to the Blueprint canvas  

• Documentation extracts covering the whole system or down to a single object

• Free choice of generative AI model

• Customizable instructions for the AI model

The Blueprint Outlines

• Programs in RPG II, RPG III, ILE RPG, COBOL, SQL, and CL

• Service Programs

• Stored Procedure, UDTF, Triggers

• Physical and Logical Files

• Tables, Views, Indexes, Constraints

• SQL Routines and Dependencies

• Object Privileges and Ownership

• Sources from PF-SRC, IFS, or GIT 

Key Benefits 

Sitemule Blueprint is designed specifically to address the pain points outlined above. Blueprint are not just reading code, it’s interpreting structure, relationships, and flow in ways that humans cannot reliably do at scale.

Why Sitemule Blueprint?

Traditional Documentation falls short

Many teams rely on manual documentation, code comments, or ad-hoc diagrams. The limitations are:

• Manual effort does not scale with the size or complexity of application estates.

• Human error creeps into every step of manual analysis.

• Documentation decays quickly because it must be updated by hand.

• No systematic cross-reference means hidden dependencies remain invisible.

Sitemule Blueprint eliminates these limitations by interpreting code at the language and compiler level, building a repository of structural knowledge you can query and visualize.

Blueprint saves money and reduces risk

Sitemule Blueprint delivers measurable business value by reducing risk and improving efficiency across the entire IBM i application lifecycle.

• Faster Development Cycles - By identifying impact early and reliably, teams can plan work more efficiently and avoid rework.

• Higher-Quality Releases - Defects due to unforeseen dependencies drop because analysis tools expose coupling and flows you cannot manually track at scale.

• Reduced Knowledge Loss - When senior staff retire or move on, the repository retains the understanding that would otherwise leave the organization.

• Better Communication Across Teams - Non-developers (e.g., business analysts, auditors) can see diagrams and documentation rather than reading dense code.

• Support for Modernization - If you modernize (e.g., add web services, refactor to service programs), tools ensure you understand legacy boundaries and dependencies.

By making impact visible and knowledge persistent, Sitemule Blueprint lowers costs, improves quality, and enables confident change - today and in the future.