Thoroughly Modern: The Smart Approach to Modernization – Know Before You Go!

September 14, 2020 Daniel Crépeau

In today’s rapidly changing digital economy, the ability to keep up, compete and quickly adapt is critical. Every industry, from transportation and logistics to banking, retail, insurance and even manufacturing, is facing business challenges that are forcing them to think about how they can manage change and be ready when disruption occurs.

Like many others, your organization probably had to evaluate how your systems could adapt to the changes that occurred over the past several months. Here’s an example that you might have seen in your own neighborhood: Restaurant #1 has been developing the ability for customers to place orders online. Restaurant #2 didn’t build this capability. When the economy shut down, Restaurant #1 was set up to take advantage of the emerging online economy and withstand the storm. Restaurant #2 wasn’t in a position to adapt to their customers’ change in buying habits. They were already operating on tight margins and without revenue, they were forced to close.

Could something similar happen in your industry? Probably. While many organizations that rely on IBM i applications knew they had to modernize pre-2020, the economic shutdown and its impacts have shown how imperative it is to improve agility. Modernization isn’t just about keeping up, it’s about anticipating disruptions in a world that is evolving at a rapid pace. Organizations are also scrutinizing where they invest, which means that it’s critical to have a solid understanding of the business value, evaluate risk, and prioritize projects based on outcomes and time-to-value.

In the IBM i world, there are plenty of options on the table, including manually rewriting your applications, purchasing a package replacement, modernizing your existing applications, and doing nothing. In this article, I’ll outline things to consider with each of these approaches and some potential gotchas that you’ll want to watch out for.

Rewriting Your Applications

Some organizations choose to rewrite their applications using modern languages. This approach has some advantages: It’s easier to find readily available skills going forward, applications are easier to maintain, and the rewritten applications are often more compatible with web technologies.

However, the human factor is a big risk when rewriting applications. IT leaders will need to ask themselves: Do I have the skills on my team to take on a project of this scale? If not, can I hire external resources? The manual effort involved means that this modernization option is going to be costly. With this approach, it will be important to budget for testing because you’re essentially reinventing your QA processes for the new applications. Quite often, we see companies underestimate the time it will take to thoroughly test the rewritten applications, which leads to significant overruns.

In many cases, scope creep and rising costs jeopardize the delivery of these projects. You might have a rough idea of where you’re going but ultimately the human component is difficult to control, especially when IT and the business are not aligned from the beginning. This disconnect can mean that projects drag on far longer than expected, increasing the chance that the new applications won’t be delivered on time or on budget.

Package Replacements

Choosing a package replacement works well – for certain applications. A financial package is a great example of a back-office system that isn’t typically a differentiator and therefore makes a great candidate for package. Let’s face it, a solution that can be implemented, managed and supported by a third party is attractive. Most companies feel this option will take the heat off IT and free up resources and budget. When moving to a package, you don’t have to write the code, which solves the rewrite problem, right? Not necessarily.

Quite often, the technology does not completely align with existing business processes. I’ve seen many organizations that have had to change the way their business operates to align with the package, resulting in serious business disruption.

Here are some other things you will need to consider:

A cloud solution might not be as secure as your IBM i system.
IT processes and security built to support regulations (e.g. ITIL or COBIT) might be bypassed, leading to compliance issues.
What will it cost to customize the package to fit your business needs? Expect that some level of customization will be required. We typically see upwards of 40 percent.
Who will test these customizations?
Who will maintain or evolve the package going forward?
How long will it take to train end users on the new technology and processes?
How will you handle any customizations when a new version is released?

When companies consider the price of the package, they often underestimate the true cost while overestimating the result. The initial price that you receive is often predicated on assuming that the package fits 100 percent of your organization’s need. While a package is less risky than rewriting from scratch, an organization requires the capacity to interpret the user and company needs from a process point of view and align them with the technology, not the other way around.

The Cost of Doing Nothing

That brings us to a third option: Status quo. While doing nothing seems inexpensive, the risk can be significant. Decision makers might look at your TCO and question why it would make sense to modernize when the project costs three times the operating budget. If it ain’t broke, don’t fix it! This could lead to a decision to simply keep the lights on like you have done for 30 years with minimal investment.

As time goes on and the professionals who know your core system retire or leave the company, your operational and reputational risks skyrocket. Imagine experiencing a transaction-based failure three days before Christmas. That’s a disaster in itself. What if the person who knew the system had just retired and you haven’t been able to find someone with RPG skills to take his or her place? You can’t predict when a system will fail so it’s critical to have someone on hand who is able to fix the system.

Also consider your customers. Are you providing a top-notch customer experience? How does your organization compare to others in your industry? What angle might potential disrupters take to capture the attention – and wallets – of your client base? Can your systems keep up in an increasingly digital economy? Perhaps 80 percent of your traffic is online but the system was designed to support 30 percent of that traffic. You could probably buy more hardware to bandage the problem but that doesn’t address the ever-pressing need for agility.

Your organization might have been saving money for 30 years by running your applications largely as-is, but the risk and technical debt has also been growing over that same time period. Many companies are coming to realize that the cost of doing nothing is high, and it’s time to make a decision for the future.

Code Transformation and Phased Modernization

Taking an automated tool-assisted approach to innovation has without a doubt proven to be less risky and less costly than other approaches. It gives companies the ability to stage their modernization investment of resources and dollars while leveraging their legacy applications and the competitive differentiation that they contain. Modernization shouldn’t break the bank or close the company.

Organizations need to be competitive, they need to be agile with modern technologies, and they need to innovate, but investment needs to be done wisely and into the right areas. A staged approach provides the ability to create the perfect modernization and transformation journey that is right for every company.

Some might say that transforming RPG, COBOL, or Synon to modern languages introduces risk because current developers might not have experience with the new technologies. If anything, you reduce risk when transforming to modern languages because you are likely going to experience skill shortages as existing developers retire. This risk extends across all of the approaches we’ve discussing today. When you purchase a package, it might be written in Java. If you rewrite, you’ll move to a modern language.

When you look at the future of your IT organization, you want to have access to people who are trained in modern technology and using these technologies becomes a benefit instead of a risk. How you get there is another question. A phased approach enables you to solve immediate business and technical issues (e.g. programming language, the databases, getting to the web), then you are able continue to innovate, evolve and add new functionality. Taking advantage of automated, tool-assisted modernization can get you there faster.

A Discovery Helps Determine Which Approach Is Best

At the heart of everything that Fresche does is our commitment to aligning your business goals with technology. We developed a comprehensive Discovery process that:

Aligns IT with business
Establishes a technology roadmap
Develops your resource strategy (people and budget)

Regardless of the strategy and plan that gets produced, this exercise helps prevent scope creep by ensuring everyone is on the same page before you get started. Our experts take the time to understand your business and evaluate the quality of your code and data so we can identify areas of opportunity that you might not already be aware of. Having completed many large discovery projects for different industries, we are in a unique position to evaluate the business value while considering other critical aspects such as change management, testing and deployment options.

A Discovery gives you the opportunity to examine the business strategy and how efficiently technology can be used to support it in a competitive environment. Setting benchmarks and goals also allows you to measure the value of everything you’ve modernized, regardless of the approach that is chosen.

Our experts have access to tooling that gives us the ability to quickly understand and analyze your technical environment so we can see where you might be able to achieve quick wins and demonstrate value without impacting day-to-day operations. Analyzing your environment also gets us closer to understanding the final costs and any potential risks. We can easily see the parts of your system that you use the most and prioritize modernization in those areas, enabling you to choose not to tackle unused or infrequently used parts of your applications.

The Discovery process is key because it provides a good risk analysis while helping you build the business case for your project. This is critical because IT is a cost center in most organizations, which minimizes value. As a result, many organizations have eliminated their capital expenditure in IT. Without a budget, how can IT innovate? You need to be able to bring business and IT together to communicate the value of your modernization initiatives, and a Discovery helps you accomplish this.

At the end of the day, justifying a modernization project can be a tough task. It’s beneficial to have access to people who have managed similar projects because they can bring the technical requirements together with the business needs and more accurately estimate the time, cost and risk involved.

Where Do We Go from Here?

Today’s companies must evaluate their mission critical applications to make sure that their system is competitive. In my opinion, a system that can adapt technologically and business process-wise is competitive.

The pace of innovation outside of the organization will almost always outpace the creativity within the organization. Some IBM i professionals that I’ve had a chance to speak with have shared that they’re not typically looked at as innovators within their organization. I would reverse that and say that the strategy of the business has not been creative toward technology.

Companies are looking at their competitive capabilities, not just for today, but for the future. If you are going to choose a modernization direction, you have to look at the risk, costs and have a good understanding of your desired end-state. Using your legacy application as the foundation for digital innovation is a low risk, low cost way to bring your systems to a competitive state that is modern and open.

If you’re seeking better, faster ways to deliver powerful new digital experiences for your customers and employees, join us on September 22 at 11 a.m. ET for a webinar with Fresche’s Nick Hampson and Chris Koppe. They will cover the various stages of a transformation project and discuss how transforming your RPG and CA 2E (Synon) applications to modern languages enables you to embrace open source, cloud and web technologies. You can register here: https://hubs.ly/H0w78lC0

This content is sponsored by Fresche Solutions.

Daniel Crépeau is President and Chief Executive Officer (CEO) at Fresche. Daniel brings more than 36 years of experience in information technology, system integration and large outsourcing contracts. As President and Chief Executive Officer (CEO), Daniel sets corporate goals, maintains Fresche’s global leadership position in IBM i modernization and management and maximizes the company’s shareholder value. Over the course of his career, he has demonstrated the ability to manage fast-growing companies in line with profitability objectives and a commitment to customer service. His leadership has allowed him to form successful teams committed to the success of organizations.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search