Thoroughly Modern: Making The Case For Code And Database Transformation

September 13, 2021 Robert Arce

The last 18 months, we have seen many companies shift their IT plans and prioritize digital transformation around internal and external access to their systems. Some had started their modernization efforts which made the transition easier while many others who thought they had plenty of time had a rude awakening. So many ways of doing business have changed – and they have changed forever. In the face of such rapid changes, companies have realized that IBM i modernization is inevitable.

Simply put, it is about figuring out:

How to enhance an application by applying best practices, creating resilient code and providing it to end-users faster
Enabling better integration with mobile or cloud-based applications
Providing stakeholders with direct access to valuable data that they can exploit
Understanding which tools can help developers offer some innovative ways for the business to gain new capabilities

Modernizing at an incremental pace has proven to be best, least risky approach: you can keep your applications, start building API layers on top of them and even connect those with new cloud native or container-based workloads – if that’s what you need to do. This results in incredibly low latency communication with high bandwidth, added security and economic benefits – all this while, you are still leveraging your existing investments in technology, people, and skills.

Making A Case for a Multi-Layered Architecture

It is exciting for developers to go from a monolithic set of applications to smaller units in the form of containers and microservices – it has changed the way they build apps. Deconstructing an application into different tiers – such as database, web, application server, mobile – can help release units of working code or functionality into the hands of end-users much faster and give developers the flexibility to make changes in one area without affecting others.

For example, for companies that have monolithic applications it can take months, in some cases years, to implement major changes such as resizing a field like the customer identifier or implementing a new contract to support an acquisition. But now, businesses want certain things like mobile front-ends to be delivered in much shorter time frames – within weeks or even days. This can be done faster and much easier by breaking the application into smaller parts that can be deployed, managed and operated independently.

The importance of creating multiple layers when you modernize your architecture cannot be stressed enough. Multi-layered architectures give you:

Increased flexibility and agility
Change one thing without affecting others (separation of concerns) and successively reduce the time taken to make such changes
Enable scalability
Establish a collaborative framework to specialize in areas that provide the most benefit to the company
Achieve CI/CD (continuous improvement/continuous development)
Better consistency and establish appropriate standards

Creating An Application Modernization Strategy

While considering your options, start at the portfolio level. Assess all the different apps that are running in your IBM i environments and ecosystems to make a broad determination of what characteristics they have and the value they bring to the organization. These steps can help you come up with the best strategy for each application or component that is aligned with the company business goals: specific application characteristics require different strategies such as rewriting, modernizing or implementing replacement packages.

Helpful Questions to Ask While Creating an Application Modernization Strategy
• Is it a commodity application?
• Does it support today’s business needs, or does it need to be improved?
• Is this where you want to drive innovation in the business?
• Do you want to preserve existing processes because they contain the secret sauce of your business, the thing that differentiates you from your competitors?
• Do you need to retain control of the application architecture?

Replacement packages are expensive and very disruptive to business processes. Rewrites are inherently dangerous, time consuming and often fail. Modernization is usually the least expensive and least risky option by far, as it lets you leverage your current investments and evolve them.

Most companies on IBM i that use RPG as a language within their code base are facing a fork in the road now. You can choose between:

Remaining in RPG for the next couple of decades and evolve it to achieve a modular architecture that can improve agility and maintainability
Or making a shift in the open-source direction (such as Java, PHP, or Node)

Some decision makers also choose to do both: keep what they already have in RPG but build everything new in open-source languages.

When it comes to transforming your code and database, more than anything, the decision lies in choosing a language and finding the right people to handle both the architecture of the applications written in RPG and the language you choose for new development.

Business Benefits of Automated Code and Db Transformation

Modern automation tools, techniques and technologies solve many IT-centric business problems. Depending on how much evolution you bring to the code base and database, there are many business benefits to reap:

Reduction of human error – using automated tooling can transform existing business logic with minimal human intervention
Faster time to realize benefits – transforming code is also a lot faster than rewriting it
Maintaining consistency in quality – code patterns generated through transformation are similar to the ones you already have, thereby offering you the assurance of a certain quality
Lower long-term maintenance costs
Competitive time to market improvements – support for modern technologies and new features results in more agility, improved business operations, and faster launch of new functionalities

The Ideal Composition of a Multi-Layered Architecture

The base layer is the database layer with indices, views and all the artifacts. The next layer is the data access layer, on top of which the business process services are built. At the very top, you will have the user interface layer with support for APIs, web services, and restful applications.

Modern Reference Architecture – PHP

An example of this would be the use of Angular where the UI can be defined. You can adapt the same architecture to PHP and accommodate future UI changes faster by simply replacing a layer or enhancing another application with the same components or even build on those components.

Why Do You Need a Modernized Database?

A monolithic architecture on IBM i is usually a single program that has been built and added onto for the last 30+ years that now needs to support certain database features (if not all the ones supported on Db2) to continue offering business value.

Security: A database that has been modernized is not only more secure but can also be set up to defend itself. If a programmer were to run an SQL statement to delete all rows in the customer master table by mistake, a database with referential integrity would stop the action and indicate that records in other tables depend on this customer identifier. In a Db2 instance that is relational with built-in referential integrity, you can secure and create better quality data, and make it more accessible to not only the IT department, but the rest of the organization as well.
Responsiveness: Modernizing your database can help you increase the speed of giving back to your organization and ramp up the ROI you offer.
Innovation: A flexible architecture with a transformed DDL database can help you be more innovative with your business offerings.
Empowerment: Business users can be empowered with data – this is one of the biggest ways to add value to the organization. Offering direct access to highly valuable data is crucial. Additionally, you can set up access to other capabilities such as data visualization, that can further enhance the ways they interact with the data.
Futureproofing and Compliance: Once the database has been modernized, all future changes that you might need to make to the business logic might take half the time (or even less). This makes it easier to maintain your database exactly the way you want it.

It might also get to a point when modernizing might be the only way to ensure that the business is compliant with all the applicable regulations.

Modern RPG Development

When you are thinking of new developments, these are concepts to consider:

Tools: Investing in proper tools to develop a modern RPG makes all the difference – a couple of good examples are RDi and ACS, ideally you shouldn’t be using SEU. Consider what you want the UI to look like in the end, what standards you want to set, and then configure the tools accordingly.

Remember to seek out advanced tools that create a modern architecture, along with a modern language – don’t settle for ones that just convert line by line, making monolithic RPG into monolithic Java. Tools should deconstruct business logic and design and then reconstruct them into a more modern, layered architecture. Essentially, adopt a code transformation approach and focus on getting to a more maintainable state.

Rewriting the code or redoing the database by hand is a next-to-impossible task with very low ROI for the business. Transforming your database can be much simpler, with a broad set of tools that have code transformation, test automation, analysis and planning capabilities. They can help you deliver better value faster, ensure quality and offer better/new UIs.

Automated Testing: You shouldn’t be doing tests from scratch that take up 60 percent of projects – it is neither agile nor flexible, both of which are vital to the business. Automating the process helps lower your costs, speeds up time to market and increases business agility and automated delivery. Don’t let the upfront cost deter you – in a layered architecture, test automation can help you implement automated regressions that guarantee quality as you release. It pays for itself quickly.

Standardizing Data Types: Ensure that the types of data you have in a database – such as dates, date times, time stamps, etc. which can all be described in many different ways – are detailed and consistent.

DDL Table Descriptions: This can help futureproof your architecture and remove some of the more outdated parts of Db2. SQL is a great standard.

If you have decided to stay in RPG, a modern, layered architecture can help address issues around agility. Also, modern free-format syntax is a cornerstone in supporting maintainability and getting younger talent who can maintain the systems as your applications evolve.

Things to Keep in Mind

Look holistically at language and the database – it is important to look past just the code
Ensure that the business value is clear when you build the strategy – this helps you get business buy-in and ensures that the right expectations are set
Prioritize layered architecture – this is key to your database’s agility and the biggest improvement you can offer the organization
Plan as intricately as you can to minimize the effort required and leverage techniques to avoid recompilation – database modernization is not a quick conversion by any means, and these steps can help make the transition smooth for the business

Transforming your code and database is going to give you applications and systems that are easier to maintain, easier to adapt and more agile among other things. But you don’t have to modernize the code and database in one go – taking a staged approach is often the best strategy. An incremental modernization plan will give you flexibility to focus efforts in quick win areas and deliver value to the business early. Reality is, there are many options and ways that modernization can be achieved. The most important thing is to do anything but the status quo.

Every day, I help IT leaders map out strategies and roadmaps to make the best use of their resources and modernize their IBM i systems. It may be challenging to figure out where to begin and what’s right for you – but your team can work with people like me at Fresche to figure that out and break down the steps for a smooth code and database modernization journey.

For any organization that wants to learn how to go about it, my colleagues and I are making ourselves available to the IBM i community through some free collaborative workshops. If you would like to sign up, you can register for the free modernization workshop here.

This content is sponsored by Fresche Solutions.

Robert Arce is the foremost field resizing expert at Fresche Solutions. Robert is part of the global team of IT Strategists – more specifically, a group of six people selected to provide discovery services to clients that are interested in undertaking a modernization project. For the last six years, Robert also held a role in the Client Solutions Advisory team. Robert was previously the owner of a company that worked on the IBM i platform, and also worked for a big consulting firm from 1997 to 2000. Robert is considered a Subject Matter Expert when it comes to IBM i, anything RPG, and anything SQL. As for databases, his experience is not only on IBM i and other Db2 versions, but also on other databases such as Microsoft SQL Server.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search