Making a project plan is one of the most important aspects of a development initiative. In the first installment of our “What is Code Transformation” series, Brian May demonstrated how to coordinate business and technical requirements and develop an agile roadmap. Creating the foundation for a long-term project like transformation is the next phase, and the amount of time spent on this stage significantly reduces overruns and rework.

In this article, you will learn about:

• Organizing your project with the flexibility necessary to remain agile
• The tools and environment for continuous integration and continuous deployment
• Automated testing and its importance
• Building a transformation team

Let’s get started!

Creating a Solid Foundation for Code Transformation

In the first session, we discussed building our roadmap and gathering all the information we would need. Now that we have all that information, does it mean we are ready with code transformation? Not quite yet. There are still some things that we need to do to ensure that a long-term project like this becomes successful.

Our next step is to lay the groundwork. First, we can do this by looking at our roadmap and the applications going through a transformation. We must set our priorities straight, especially for a big project. We also need to plan our DevOps strategy and develop a testing strategy. We should keep in mind that automating things will speed up the process. With a project like code transformation, we will touch everything; as a result, everything will be tested. Lastly, we need to build the right team/s.

Let’s take a look at how we should lay the groundwork in more detail:

1. Organize and prioritize

Transformation is a long-term project that is not measured in weeks; most customers measure this journey in years. Think about it like climbing a mountain. You would lay out a general plan before you start climbing—the rocks on the side of the mountain. It is the same thing with code transformation; you must prepare well for this. While organizing the code transformation, we will break it into small, achievable steps that we can quickly deploy and get into our end users’ hands. We will break them down into sprints (an Agile term, a set time during which specific work must be completed and ready for review).

A few ways of organizing a code transformation project include Menus/Menu Options, Department/Roles, and Functional Areas/Business Processes.

Once we have broken the massive project into smaller ones, we need to prioritize to know what order we will proceed. Prioritizing sprints includes Technical Advantages, User Buy-In, Impact/Risk, and Potential Gains.

2. Get your tools together

Our tools mean our DevOps and Automation tools in the code transformation world. The DevOps toolchain is the Source Control, Continuous Integration (CI), and Continuous Delivery (CD). For Automated Testing, these are Unit Testing and End-to-End Testing.

What is DevOps? According to Amazon, combining cultural philosophies, practices, and tools increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products faster than organizations using traditional software development and infrastructure management processes.

We will use Open Source tools as an example of the DevOps toolchain. When working with Profound Logic, it means taking RPG to Node.js. Source Control for Node.js, the industry standard is Git. For the Repository, we have GitHub. For CI/CD, we have Jenkins.

Regarding Automated Testing, we will use Mocha for Framework and Chai for the Assertion Library for our example toolchain. For end-to-end testing, we will use Selenium.

Here’s a quick look at an example process:

• Automated steps
• Developer commits a change to the Repository (Git/GitHub)
• Change deployed to QA environment (Jenkins)
• Automated tests run over the application (Jenkins > Mocha/Chai/Selenium)
• If all tests pass, change is deployed to the UAT environment (Jenkins)

• Manual steps
• Users test changes in the UAT environment
• If approved, deployment to production is scheduled

3. Build a team

Code transformation is not the type of project where you can throw one developer at and say, “go do it!” It requires a lot of skills and expertise to be successful. No one person has all the skills and expertise; even if they do, it will take a lot of time if only one person is doing it. Code transformation will take more than just IT, so that it will need partner, IT, and end-user resources.

Identify the team roles. In doing this, we have to plan for two PMs—Profound Logic PM and your team’s PM. The Profound Logic PM will successfully know how to do a code transformation, invaluable expertise. On the other hand, you can have a PM from your team who knows how your company works and can interface more directly with the stakeholders. These two project managers can work hand-in-hand in keeping the budget, watching the deadlines, managing resources, and ensuring deliverables are correct. These PMs are not dedicated to a single sprint team. At the start of code transformation, there can be just one sprint team, but it can increase moving forward to ramp up the speed of change.

The architect is another critical role that we should identify immediately. Generally, it will come from us since we will be helping you with the transformation. You can be sure that we have talented architects at Profound Logic. In the architect position, they will serve as the technical lead who understands the big picture. The architect will be the person who will come up with solutions in case some things arise from the transformation. They will work with the PMs to make sure things are on track. Since PMs may not necessarily be as technical as the developers, the architect will bridge that gap. Like PMs, they are not assigned to a single sprint team since they are concerned about the big picture.

Next, we need to identify the transformation consultants. These are Profound Logic staff members who will do the actual code transformation. They are experts in converting RPG code to Node.js, identifying issues in the code transformation, and improving the automation of our transformation engine. When doing code transformation, we are constantly enhancing our transformation engine so that if we encounter a problem, we only have to deal with it once. When we see a situation that does not transform well, we can correct it. All other instances of that situation will be handled in the future, making the code transformation more efficient as the project progresses. They are experts in DevOps and Tooling and are assigned to a single sprint team.

There is also going to be a business analyst from your IT staff. They are necessary because they understand your business’s work, application, and architecture. They are our primary contacts who will help coordinate end-user team members, assist with manual corrections, and build automated test cases. They may be used across sprint teams depending on workload.

Lastly, we need to identify the end-user experts. They will offer suggestions for improvements during code transformation and future enhancements. They can build automated test cases and can perform user acceptance testing.

Another group to bring together regarding code transformation is the steering committee. Generally, it comprises the project managers, architect, senior business stakeholders (people from your business who have the authority to make decisions that may include spending money so that the project does not get hindered while waiting for a decision), and senior partner stakeholders. The purpose of this committee is to discuss and decide on any significant issues, approve change orders, and approve any additional expenditures.

Key Takeaway

It may seem like a massive structure, but it is necessary for a big project. It will involve a lot of teams and a lot of work. In our experience, this is what it takes. Code transformation is not a simple endeavor but a large-scale and impactful project. So, you want to make sure that it is appropriately managed. You want to get the resources and all the decisions set up ahead of time. You would not want to do code transformation and realize in the middle of it that you need to restructure or you did not set up a steering committee. Now we have to wait three weeks to get a decision from someone higher up to spend this extra money, so we have additional team members sitting around and unable to work on the project. We want to make sure that the tooling is appropriately set up so that when the time comes to start doing the actual work, we can do it and not have to worry about how to move things around.

All of this initial investment saves time and money in the long run. It is essential to take the time to get all things lined up before we even think about transforming the first line of code. Once we have the groundwork, everything should be smooth going forward. If issues arise, we have the means set up within our teams to deal with them promptly.

About Profound Logic

Profound Logic has focused on bringing modernization solutions to businesses on the IBM i platform for more than 20 years. We lead the industry with integrated solutions for green screen modernization, new application development, mobile development, open-source, and rapid development/low code solutions for IBM i. We were the first to market with a web-based Visual Designer for RPG application development and the first with a solution for RPG Open Access, making it possible to transform 5250 green screens into rich web interfaces completely.

Are you interested in learning more? Click here.

Click here to watch the first video on “What is Code Transformation?”