Planning A Modernization Project? Read This First
October 18, 2021 Alex Woodie
Modernization means a lot of things to a lot of people. If you happen to ask Chris Koppe, the senior vice president of strategy, transformation, and modernization services at Fresche Solutions, what modernization means to him, get ready to spend the next hour listening to his response.
That’s the approximate length of Koppe’s recent presentation at the POWERUp conference, titled Developing Your Modernization Plan: What Are Your Options? and it’s worth every second. Koppe explored the topic in such breadth and depth that we though it was worth highlighting his main points. Of course, if you’re a COMMON member and registered for the event, we recommend taking in the full version from Koppe himself. For the rest of you, we’ll summarize as best we can.
Since he works for Fresche, the Quebec company that sells IBM i modernization software, you might expect Koppe to focus on the tools and technologies involved in modernization projects. But Koppe spent very little time on the tools and tech during the session. In fact, he only mentioned them once or twice, and that’s just to state that they exist and are part of the equation. That’s refreshing, to say the least.
“It’s critical that modernization doesn’t start with technology,” Koppe said. “It doesn’t start with what kind of tools do I need to modernize. It starts with strategy, and strategy is really business strategy and IT strategy. We need to figure out what is it that’s happening at the business level and what does modernization do to support that.”
Having a vision of where your company wants to go, and what it wants to be, is critical to building that roadmap. Does your company seek to be the market leader in its industry? Or perhaps it already is the market leader and wants to protect that position? Maybe it wants to be the most innovative, or the least expensive, or have the best customer service? What is the company’s timeline for achieving these states?
“Once you have vision and strategy, then you can work on the mechanics of the how,” Koppe said. “Roadmaps are [about] the journey, the specifics, the plan . . . the milestones that we’re going to achieve to know that we’re being successful along the way.”
Many IBM i applications fall into the bottom two categories. (Image courtesy Fresche)
Part of figuring out where you want to go is if knowing where you are now. To that end, a company will need to conduct an application assessment to determine where they’re currently at, Koppe said.
During this assessment, applications will be put into categories that reflect their contribution to the company, such as systems of record, which is where the bulk of IBM i applications probably live. Systems of engagement and systems of innovation typically will be applications and databases directly serving customers (often via Web and mobile interfaces), while systems of insight typically are data warehouses and analytics systems.
“For the most part, on the IBM i, a lot of the systems that we’re working with are record-keeping systems,” Koppe said. “They’re keeping the transactions of the organization– accounting transaction, order transactions, customer transactions, historical transactions. A lot of that’s record-keeping, but record-keeping systems are typically commodity. If you look at accounting systems, a lot of people go to package apps for that because there should be nothing different about your accounting system or your accounting practice as an organization from what’s expected in the accounting field.”
That’s not to say that all IBM i applications are commodity and can be replaced by packaged apps. The bulk of IBM i applications in existence are homegrown (per the IBM i Marketplace studies from HelpSystems). In many cases, IBM i shops have spent decades customizing the systems to do exactly what they need. In this respect, IBM i apps often creep up from the systems of record level into the systems of differentiation level.
“One of the clients that we did business with for a while, in their industry segment, they were the only one of their competitors that could receive and ship an order in the same day,” Koppe said. “Everyone else took a minimum of two days. So that’s differentiation for them.”
The degree to which a company wants to innovate with a particular application and be an industry leader will determine the extent of the modernization and the resources that will be put behind it. For each application or module, the company should be able to describe the business impact that modernization can bring, the complexity level that it entails, and what priority the modernization rates relative to other applications or modules.
There are three main avenues that a company can go for modernization: Wholesale replacement with a packaged application; a full rewrite in a new language; and modernizing the existing application.
Companies should determine the best way to achieve their application wants and needs. (Image courtesy Fresche)
In some cases, companies may opt for a packaged application, which can be less costly and easier to implement than a custom-written system, particularly for commodity applications. In other cases, companies will be able to achieve their business goals by rewriting an existing application, or using vendor or open source tools and technologies to modernize the application.
Regardless of the approach selected, during the modernization exercise companies need to be careful to preserve the features that offered a competitive edge.
“That’s why, in a lot of cases, when you say ‘I want to replace my order-entry system with a packaged application,’ if you’re using the same packages all the other companies that do two-day order receival and shipping, well now you’ve lost your differentiation,” Koppe said.
If your company is ambitious and is looking to be on the cutting edge of technological innovation to deliver a differentiated customer experience, be prepared to take on more of the development work, because there isn’t likely to be a packaged application that fits the bill, Koppe adds.
“If you look at a company like Uber, for example, some people call them a taxi company or an alternative to a taxi company. But they don’t use a typical dispatching system,” Koppe said. “There’s dozens of dispatch systems available to taxi companies. But Uber, if they want to own the client experiences, they need to own the architecture – how everything works, how you interact with it, and the data model behind it.”
In most cases, companies will take a hybrid approach to modernization, he said. They will mix and match packaged applications with homegrown systems. In some cases, existing greenscreen applications may be good enough, and there’s not much of a reason to touch them. If there’s not a business benefit to be had from opening the application up, then it’s not worth doing, Koppe said.
“The ‘why now’ part is really difficult in the IBM i space because, for most of us, the applications that we support our have been running for 20 years or more,” he said. “They’re working just fine today. There’s very little business pain perceived from the application. There might be skill pain, like can we sustain it? Can we find enough programmers? How do we get the business to want to invest in IT? There could be those kinds of challenges. Quite often we hear about them. So if it’s all running and stable, why should we invest and why now? So we have to build a business case for doing that.”
Koppe clearly has gone down this road before, and he’s given it quite a bit of thought. While every modernization project is unique, he has seen certain patterns repeat themselves. One of the big red flags that he has identified is when IT people use IT ideas and terms to convince their line-of-business colleagues that a modernization project is worth doing.
Business leaders will respond more favorably to a modernization pitch if the focus is on boosting business drivers rather than technical drivers. (Image courtesy Fresche)
“When we think of modernization, we think of technical drivers and business drivers,” Koppe said. “In IT, we gravitate towards these things, and when we try and communicate with the business, we often try and use these words. We’re going to be able to you phone interface and tablet interfaces. We’ll have a new reporting and data mart for you, a new business intelligence analytics thing for you. We’ll be able to do predictive analytics. And we’re going to a service-based architecture, lots of APIs. We’ll be able to innovate with the hardware really easily with all these APIs we have. It’s going to be really innovative. Or we’ll going to leverage new technologies like cloud robotics and AI and blockchain.
“These are interesting drivers for modernization,” Koppe continued. “But they’re technical drivers and they don’t resonate with the business. What resonates with the business are business terms. These are things like ‘We want to be able to disrupt, or respond to disruption in our market. Amazon is coming into our market and they’re going to be disrupting how business is done. We need to respond to that quickly.’”
COVID-19 has provided abundant opportunities to disrupt the status quo, and to be disrupted by the status quo. The folks running the business are abundantly aware of the market and what it’s demanding (or they should be anyway – that’s their job). To really succeed in a modernization project, Koppe basically said, it’s critical to make the business case to the business leaders, without getting bogged down in fancy whizbang technology.
“If you want to build a proper roadmap and a proper strategy, we need to think about how we are realigning our modernization plans and goals to our business strategy,” he said. “It starts by understanding our business strategy. What are the strategic imperatives of the business? What is it that’s driving the organization today? And if you don’t know it, go ask an executive. Go ask your CEO. Go ask for a session with IT, ask your CIO or somebody else in in a leadership position, hey explain to us the three- and five-year plan.”
Once the broad outline of the roadmap is hashed out, then the details can be filled in. Which application goes first? When will work commence? When should the project be completed? Will multiple applications or modules be modernized or rewritten or replaced simultaneously?
And there’s a lot of other things that need to be done. “You need to get yourself educated on tools. You need to do an inventory of code and you need to do risk assessment and we need to figure the business case fundamental and the funding model and the cost predictions for year one, two, three,” Koppe said. “There’s a lot of other things that come to play. But in the end if you do this part properly, you’ll end up with a fact-based understanding of the applications. You would have documented the business value of every step in the transformation journey, and what the business gets out of it, and why they should care and why now.”
As was mentioned earlier, it’s refreshing to get a glimpse of the true complexity that goes into these projects. All too often, vendors, consultants, and systems integrators gloss over the gory details that comprise modernization projects.
Modernizing large swaths of enterprise software is a risky endeavor, and so it behooves businesses to start with a clear-eyed assessment of those risks, as well as the rewards, which should be commensurate with that risk. Failure to undertake these steps – or to implement the rigorous project management necessary to see such a big undertaking to fruition – simply is a risk that companies can’t afford to take.
RELATED STORIES
The Mod Squad Comes Together to Modernize Old RPG
Fresche Takes On New RPG Development And Modernization With X-Elevate
COVID-19: A Great Time for Application Modernization
Modernization Trumps Migration for IBM i and Mainframe, IDC Says
Alex, find overview. Much appreciated!