How to use your most modern asset in modernization efforts?
What's modern about 2E applications? Even ones developed in the '80's? If you can answer that question you've got a an excellent start towards reengineering your applications.
What's not modern about 2E?
The code that you see – the generated code - is certainly not modern. Besides being RPG IV, it is also monolithic, procedural, and runs only on a single mainframe-style platform deployed in the '80's.
It also has the unfortunate trait of being impractical to maintain the generated code.
Arrange for a Demonstration or Free Trial
What would a modern version of a reengineered 2E application look like?
These traits would include:
- Constructed in a modern, multi-tiered, object oriented, stateless architecture
- Constructed of recovered, cleaned-up business rules, data models and workflows
- Free of extraneous remnants of legacy code infrastructure that are no longer relevant
- Human-readable, with appropriate long names for objects and variables
- Highly maintainable, to ensure lasting value for many years
- Coded in a modern language of choice, such as Java, C#, JSF, Silverlight, etc
- Free of anything that ties it to a particular vendor or makes it less than 100% portable
What's Modern about the 2E Model?
Because Synon forces users to organize code into screen designs, action diagrams, business logic and database components, by working with the internal 2E model it is possible to extract design information in a structure that maps cleanly into a modern MVC/OO/REST architecture.
Visual Guide to Synon and 2E Reengineering

Just to be clear, it is only possible to do this by converting the 2E model itself into the target architecture and code. Conversion processes that attempt to translate the 2E-generated RPG code will result in volumes of unnecessary, unrecognizable, unmaintainable code.
Best Practice Processes: Manual and Automated
There are two general approaches to migration: manual reengineering and automated reengineering. In either case, best practice reengineering is premised on reuse of proven business designs. These designs are primarily found in three forms in a CA 2E SYNON Model. Amazingly enough, you will typically end up representing most of this same knowledge in your new system.
The first diagram below shows a high level view of the 2E model recovery process that recovers information for two distinct purposes:
- Analysis and documentation of the 2E application
- Reengineering and conversion of the 2E application into another architecture and set of languages

The following diagram shows how design recovery from the 2E model can be used to feed the analysis and redesign processes.
How 2E Design Recovery Feeds Analysis and Redesign Processes?

This diagram provides an overview example of how 2E model information can be automatically reengineered into a modern architecture and set of languages.
How 2E Design Recovery Feeds Automatic Reengineering?

In manual reengineering projects the existing 2E information shown above would be recovered and used to feed the requirements and design phases. This type of information is all recoverable with Databorough's X2E product and can be output in numerous formats, including Word, Excel, XML, DDL/SQL, UML diagrams (Activity, Class and Use Case) and so on.
In automated reengineering projects the existing 2E information, Databorough's X2E product contains intelligent robots that recover knowledge chunks and reassemble them into a new system. Importantly, that new system realizes all the goals described above for best practice reengineering.
Best Practice Architecture
The software engineering world is a long way from settling on any single best architecture or programming language. But it’s pretty clear by now that over the last 10-20 years some favored practices have emerged. These include:
MVC design pattern – Model-View-Controller, as in a Model layer of components that contains business logic, a View layer that contains the outward presentation, and a Controller layer that handles events in the other layers and directs process flow.
Object Orientation – organization of code into objects, the proper term being classes, and those classes containing functions. Those functions being either callable from other classes, or protected, so they can only be called from within their own class.
RESTful interaction – in particular, the most salient point of REST being that server components have no inherent knowledge of session state. Session information that needs to be preserved between work flow activities (screens) is preserved and represented from client-side memory, or via session management functions within the application server software.
Why This Architecture Is So Doable with 2E?
Getting back to the question at the beginning of the article, what is so modern about 2E applications?
Because Synon was originally designed to organize code into screen designs, action diagrams, business logic and database components, by working with the internal 2E model it is possible to extract design information in a structure that maps cleanly into a modern MVC/OO/REST architecture.
To reiterate a key point , it is only possible to do this by converting the 2E model itself into the target architecture and code. Conversion processes that attempt to translate the 2E-generated RPG code will result in volumes of unnecessary, unrecognizable, unmaintainable code.
And getting back to those best practice reengineering goals, by using Databorough’s X2E product you can be certain to realize these goals in the most cost effective, timeliest and highest quality manner possible.