Welcome back to my three-part series that looks at IBM i programming languages. My goal has been to cut through the emotion and identify what “legacy” really means when it comes to programming languages on the IBM i (aka AS/400, iSeries) platform.If you missed part one, catch up here, and part two here.In this last blog entry in the series, let’s cover what is most important. By that, I mean when it comes to programming languages, what are the top things to consider when transforming your business?The first conversation that typically takes place surrounds which target language makes sense for your specific business needs. Please realize that the answer to that is as individualized as your organization. If there is a solid case for modernization, the real question is what does modern code hope to solve?General considerations should be:

• Resources – What are your current programmer skills, and how long will those skillsets be at your disposal? If you don’t see those skills supporting you for the next decade or so, then choosing a language or a version of a language where skills are easily procured and learned seems to make sense in securing sustainability for the future.
• Platform – What concerns are there, if any, regarding the platform you are running? Are there multiple platforms of which consolidation or integration would aid? Does the programming language tie you to one of those platforms, and is that platform strategic to your future or not? Is the platform legacy, or is it the code?
• Application Classification – stated differently, what is the value of the task that the application performs for the organization?
  • Is the application considered a System of Record? In other words, is it the authoritative source of truth regarding key points of data within your organization (typically some type of ERP or CRM application)? If so, these applications many times hold the keys to the kingdom and great care should be taken in regards to modernization and transformation initiatives in order to manage and reduce risk.
  • Is the application considered a System of Differentiation? These systems are typically considered mission critical to an organization and provide competitive advantage in some way. You can consider these systems “the secret sauce” that keeps the company ahead of its competition. Stated differently, these systems could never be replaced with a COTS (commercial off the shelf) application without it negatively affecting the organization. When organizations are considering digital transformation initiatives, these extremely valuable systems are typically the primary focus of transformation so that the competitive/differentiated edge can be maintained and enhanced.
  • Is the application considered a System of Engagement? Whereas systems of record are the source of truth, they may not provide a straightforward way in which employees/partners interact with the system. As such, systems of engagement are developed that focus on engaging employees in a way that makes sense to them and the task at hand, and these systems then typically have a tight integration with the system of record/distinction. Therefore, as you modernize/transform the system of record and/or distinction, you must consider these systems of engagement that are relying on those applications.

• Database – There is a very telling comment that says, “without data, you’re just another person with an opinion”. It has become clear that business can’t make valid and factual decisions without clear and timely data, and therefore without that data, business initiatives are potentially doomed. Is the data provided by your applications sufficient? Is the data available outside of applications for those that need it? Is the data formatted in a way that makes it intuitive for analysis? Is the data architected to support AI, governance, quality, machine learning, etc.?
• Modernization Options – How will the code you’re currently using impact your business application modernization options? If so, which of the following option will help you achieve your modernization goals?
  • Buy packaged applications (rip and replace)
  • Automation to transform code
  • Manually rewrite
  • Integrate
• Integration, API, and Innovation – Business operates and thrives on disparate systems, but those systems create more technical debt and typically prevent seamless, scalable, dynamic, and durable integrations. Do you currently have solutions to deliver the connected, portable, applications your business needs? And if you do, how do those co-exist as part of your transformation strategy?
• And the Code itself – Amazingly, you will get a different answer about code assessment from almost every person in your organization and/or ISV. But everyone has a valid position that must be listened to and incorporated as needed into your strategic roadmap.Keep in mind, at this stage of the process, this is all over-simplified anyway as code is simply the easiest and most-straightforward way to talk about “why modernize” at an elementary level, and a person’s stance changes as a more holistic and future-state view is discussed.

The bottom line is: If you begin to talk about moving from one language to another, the question of “When do modern languages become legacy?” MUST be part of your thought process. Let’s take a look at the primary options from a high-level perspective:

• RPG – Keeping your code where it is can certainly be an option. Many hold tight to the idea that “if it ain’t broke, then don’t fix it”, but for that stance to be a strategy instead of just a position, you must balance it with an acknowledgement that if and when you decide to “fix it”, it might be too late. But if your code gives you what you need and doesn’t negatively influence the other areas addressed in this article, then move on to disrupting in a different manner.
• RPG Free – This option might make sense if you need to be a little more modern but overall, the business is operating fine, and the language and/or infrastructure is not holding you back.
• Java/.NET – These are both middle-aged languages nearing the designation of “legacy”. Think back to the analogy…if you are an avid VCR aficionado but also recognize the need to move to a new technology, you might move from VCR tapes to DVDs. DVDs are newer, but not the latest and greatest option for consuming media. The same may apply if you are thinking from moving from RPG to Java or .NET. Both are solid languages, but certainly not as modern as some newer players.
• js – Many claim, and I agree, that Node.js is the new standard for enterprise application development. Node.js succeeds in creating real-time applications and microservices, and it’s increasing business-focused footing quicker than any other technology for multiple reasons. These are the reasons why Profound Logic introduced their RPG-to-Node.js transformation services. This automated service is an amazing opportunity to reduce the risk, cost, and time needed for traditional modernization projects.
• Others – there may be noise about other languages du jour, but don’t get caught up with those without having specific purpose in mind. Whereas there are some really new, cool, promising languages, we are limiting our discussion to those languages that are enterprise-ready, mature enough to have proven their stability, and for which the market believes that there is enough demand that automated tools have been created to aid in the transformation.

Without a doubt, there are many moving parts to the transformation engine, and the programming code your business uses is just on part – but it’s a key part. Although it seems like a detail that only technical users on the IT team would be concerned with, the code you choose for your IBM i modernization projects is vital to supporting your current and future business projects. It also assures that your IT and Business are aligned. This is why you need to address these areas in advance.Fortunately, Profound Logic has the skills and expertise to help you on your way! Reach out to us at services@profoundlogic.com and we can start exploring your business’s modern future, together.