Getting Offensive With The Legacy Label
April 24, 2017 Dan Burger
It’s not that we don’t care about CIOs with concerns. But what concerns us more are solutions to those concerns. It’s just a matter of fact that we hear a lot more about problems than we do about solutions. Members of the IBM i community share many of the same concerns, although each has their individual fingerprints.
To start off down the problem-solving path, it’s not a bad idea to talk about common concerns with colleagues and experts. That’s the path we’re on today as we talk with Alan Seiden, a PHP on IBM i consultant, open source advocate, facilitator, and problem solver.
In his years of interaction with CIOs, Seiden says the obstacle most often mentioned is the loathsome legacy label that’s slapped on the IBM i platform by CEOs and other members of executive management. When assessing the situation and attempting to successfully navigating the choppy waters, it’s best to get some assistance rather than go it alone. Here’s some advice Seiden has gathered.
Alan Seiden
“CIOs say it’s important to separate the applications from the platform,” he says. “The platform is very modern, but it can be running applications that are 30 years old. That’s both a strength and a weakness for the platform. You can’t be a cheerleader only and be blind to the weaknesses. Often when the business people speak of the AS/400, they are really speaking of the applications. It’s not just the green screens. It’s that the AS/400 can’t do this or that. It’s because their application can’t perform and it’s because the applications hasn’t been improved or updated sufficiently, or perhaps can’t be. One reason could be that the app is monolithic and can’t be divided into service programs or even better green-screen programs, for instance.”
Going to executive management with a plan to make gradual improvements that aren’t perceived to be functionality improvements is generally ineffective. Intentions to modernize applications and databases are often derailed because the functionality story is perceived to be lacking. Some CIOs are saying the term “modernization” is part of the problem because it is being directly associated with the IBM i not being a modern system. A point of emphasis in executive discussions should be that all software needs to be updated, not just IBM i software. Outside of the IBM i environments, the term modernization isn’t used. It’s called refactoring and its purpose is updating the standards from the time when the code was written up to the standards of today.
“Providing a graphical user interface is modernizing,” Seiden says. “But improving the quality, adaptability, performance and ease of maintenance or performance of our code – and other resources such as the database – doesn’t immediately increase functionality. That’s the definition of refactoring. Every development language requires this.”
It’s important to communicate with the business people about the need to refactor. Although the details of refactoring may be wasted on a jury of non-technical executives, it needs to be explained that every piece of software eventually needs to be refactored to support business changes as well as technology changes. It’s an industry practice and part of the cost of developing software and running an IT shop.
Refactoring allows application and database changes to be made more quickly. Part of the stigma that comes with the legacy label is that systems are incapable of quickly adapting to change. The reason for that, it must be understood, is because applications and the database have not been kept current, not because it is incapable of being modern.
Explained that way, CIOs have increased the odds of getting buy-in from CEOs to do gradual refactoring.
“Most shops know where the skeletons are hidden – the areas that cause repeated problems and need the most attention,” Seiden says. “Usually they do the worst first and move gradually and carefully. You don’t want upheaval that will ruin the reputation of the effort.”
Having metrics that can measure ROI will help in the communication with business executives.
“Some type of an attempt has to be made to show return on investment,” is what CIOs have told Seiden. “It could be soft costs such as developers spending less time on refactored apps than apps that remain unchanged. That adds the ability to more easily add additional features or improvement of quality, possibly relating to the company’s reputation.”
What works best is knowing what the CEO wants to hear about and what boxes he or she wants checked. Be prepared to name problems and explain how solutions will solve problems. The explanation must be tangible and practical when explaining the benefits of modernization or refactoring.
The term technical debt is used to describe situations that accrue when code is more or less abandoned while the programming language moves forward with enhancements. When the necessity for upgrading finally comes, the process will be slower and more frustrating than anyone would wish. Changes can affect dozens of programs and hundreds of users. The effort to make the necessary program changes may require a serious undertaking and considerable risk. But without that changes, every small change will require more time and risk than what’s necessary after the refactoring.
CIOs have told Seiden the message to the decision makers should be that taking a controlled risk now will save time and problems later. And doing nothing incurs risk as well. There are many years of exceptions factored into the existing code. That’s all thrown away if a CEO decides the legacy system needs to be replaced with something new. It’s better, cheaper and easier to keep what’s in place in many instances. There also is a hard line on some of this refactoring when the only people who can maintain the old code are in range of retirement.
It’s a calculated decision. Devoting time to modernizing and refactoring most likely means other things don’t get done if staff is already pressed to its limits and no permanent or part-time staff is hired.
Talk About The Cloud
Getting outside the legacy technical debt conversation, CIOs are talking about the cloud. It’s not a discussion of whether the cloud is simply good or bad, but is it appropriate for a given application on a case by case basis.
As expected, CIO responsibilities involve examining costs and benefits relating to availability, scalability, and security threats. The perception that public clouds are risky still exists and the opinion persists that running on an IBM i in-house makes organizations less likely targets.
There’s also the CIO responsibility to point out to the executive management that cloud does not absolve CIO management. There remains some degree of responsibility on the customer. And it’s a mistake to think the cloud will totally externalize costs, problems and responsibilities.
Improving Workflow
“With the complexity of Web applications, it’s hard to have one person handle all parts of the application development process,” Seiden says. “CIOs are placing more emphasis on app quality and frequent releases and updates and this is finding its way into the IBM i world.”
One of the biggest changes he sees is the increased use of automated testing strategies–unit tests and end-to-end tests that ensure apps are running correctly after changes have been made. Automated testing is popular in the open source communities, where Seiden has found a niche first with PHP and more recently with other open source environments that are supported by the IBM i operating system.
Also in the realm of open source, the CIOs that Seiden interacts with are showing interest in the integration of remote members into team development. It allows the best talent, regardless of their locations, to be brought to projects by incorporating tools for conference calls, sharing project information and using source code management repositories like GitHub and BitBucket.
“Teams can work from anywhere with the capability to merge code and review code. It helps get coders out of siloes, where developers know their own single applications but no one knows multiple applications, so there is no crossover. SQL can be managed and merged too, making database refactoring part of the mix,” Seiden notes. His own company, Seiden Group, makes use of these workflow tools.
Dictating Technology
CIOs need to be prepared for questions coming from line of business stake holders who want to dictate technology. Their advice here is to take the questions seriously, evaluate the suggestions, and keep on top of solutions that are alternatives to what is currently running.
“It’s the CIOs job to prove IBM i is right for the job or not,” Seiden says. “Think about it honestly and without bias. To be prepared, a CIO needs to talk with other CIOs. It’s important to have a community of peers and find out what actually happens during an implementation. It’s important not to be dealing with these questions alone. Other CIOs have other backgrounds. Some will be more technical. Some more business oriented. You don’t have to have all the answers in your mind.”
RELATED STORIES
The Feeds And Speeds Of The IBM i Base
IBM i Priorities For 2017: Pivot To Defense
IBM i Trends, Concerns, And Observations
Five IBM i Facts That Will Surprise Your CIO
CIOs Move From The Back Office To The Front Lines
