IBM i > Developer > Modernization

Steps to Modularity

Everyone’s talking about application modernization and the application-development industry has fixed on modularity as the key to a modern application. This is true regardless of platform, language or tooling. Smaller components of code should be focused on specific tasks.

When considering modularity, programmers must take a huge step away from where they’re comfortable and rise to the level of application architecture. The term “business process” is often used in this context. Application architects must understand the underlying business process that the code is automating. Once the analysis is done, individual business functions can be identified and connected to create the business flow of an application. Take order entry, for example. Without talking about programming (languages, op codes, etc.), specific, unique business tasks can be identified as part of an order-entry business system, such as 1. entering the order, 2. checking for a valid customer, 3. checking inventory, etc.

Once business flow has been identified, the next step is to mine the application for gems of code that already exist. Examine the program code and see if some of it can be repurposed or repackaged and included in the new modern architecture. Depending on the quality and functional isolation of the old code, it might be recycled and pieces used to populate the application architecture. This is certainly easier said than done. It takes time to crawl through code and determine which pieces are valid for reuse. It will be necessary to write new code to fill in the missing components or connect the recycled pieces together. This new code should be modular, too.

Modernizing the total application structure is an extensive undertaking. It means identifying and separating the various functions into components—user-interface layer, business logic, data access and printing—and placing them into their own modules. This is a challenge, and not only because of the labor; it can be hard to convince management to invest the time when the results are not as obvious as a refaced application. The benefits, however, outweigh the difficulty.

Follow these distinct steps to move existing programs into a modular structure.

Ensure that the existing application reflects the most current version of the compilers. IBM is not enhancing older versions of the languages. All new functions and features are being added to the latest compilers—RPG IV, ILE COBOL, ILE CL, 64-bit Java, etc. So, as integration with other languages such as Java and XML is added, these functions are unavailable in older compilers.

Analyze the existing code, seeking specific functions to be isolated. Typically, business logic, user interface, data access and printing functions are separate from one another. A few tools in the marketplace can help in understanding the existing code and providing excellent documentation to assist as the developers make decisions on modularization. However, no tool can automate the isolation phase. This is not a bad thing! It’s the people with business-domain knowledge (programmers who originally wrote or who now maintain the code) who truly understand the code. For example, an automated tool wouldn’t understand that two subroutines called “DATE” are actually achieving the same conversion, because they reflect completely different coding styles.

Consider breaking up all functions during one pass through the code, rather than going back numerous times, each with a different objective in mind. For instance, while separating user interface might be the first objective, this is also a good time to examine data access and split it into separate modules or stored procedures.

Identify repetitive functions and consolidate them in one place. This is easy for processes that are the same, such as numerous instances of date routines from multiple programs being converged into one routine and placed in a service program. And some independent functions are not quite so obvious. For example, file checking routines done today in program logic should be moved into the database in the form of referential or check constraints.

Once the application has been separated into components, it becomes easier to update functions. Isolating the functions and coding them as separate entities protects a developer from the burden of changing an entire program to implement a new function. Instead, the programmer will need only to replace the few modules required to render the new images. For example, once the modularization process has isolated the user interface layer, it’s far easier to replace the green-screen module with a new piece of code to produce a graphical interface. This modernization is the most visible to the business and many development shops use this as the justification to tackle modularization.

Tweet