by Chris Durand
Say you have an existing iSeries (AS/400) or mainframe “green screen” application. It’s been around for a long time and has a solid, reliable code base based on years (decades?) of testing and real-world use. It generally works pretty well, and doesn’t change much.
That’s all great until you find that as the business is moving forward it is becoming increasingly difficult to update the application to support the future business direction. Sure, you’ve found a few creative solutions to work around application limitations so far, but fundamentally you need something other than a short-term fix.
You basically have the following modernization options:
- Rewrite it using the language/technology/platform of your choice.
- Pros: Complete flexibility to keep what is working and rework what is not.
- Cons: Expensive. Risky (does anyone really know all the business rules buried in decades of code?). Slow to implement.
- Convert the code to a new platform using an automated tool. I’ve not had experience with this, however, I suspect it is cheaper than rewriting, but still very risky. Plus you probably don’t get the full benefits of a true rewrite.
- Service—enable it. Everyone loves web services today.
- Pros: Leverages existing host logic, so it’s less risky than a rewrite. Enables your application to exchange information with other applications.
- Cons: This is primarily an integration strategy and does not do much to improve the application itself.
- Re-face it. Re-facing is the process of adding an additional layer between the user and the system. This layer can then convert the interface from the green screen to something else—say, a web application.
- Pros: Fast and cheap. Moderate flexibility to change existing application behavior.
- Cons: Not as flexible as a rewrite. Increased support costs. May incur licensing fees.
I’ve worked on a number of these sorts of projects and found that re-facing is often a good solution. (And of course if you want us to re-write your application from scratch, we’re happy to help!). After many re-facing projects I have found the following to be true:
- Re-facing is more flexible than you think, but it does have limits. Re-facing offers substantial scope for creative developers and architects to change the application. Workflow-related issues can usually be changed, and new functionality can usually be bolted on, but core business logic often cannot be realistically changed. So if you like how a shipping charge is calculated but not how the user has to enter shipping information, re-facing can help. But if you don’t like how the shipping charge is calculated, you usually need to fix this on the host.
- Maintenance costs are minor *if* you choose the correct application. Re-facing is not a great choice for applications that are still being frequently changed on the host. Each time you update the host, you may also have to update the re-faced screen to match the new functionality resulting in “double maintenance” costs. If the application doesn’t change much, however, these costs are modest in exchange for the application’s new lease on life.
- It’s more than a short-term solution. Many re-facing projects are started with the intention of being a 2-3 year solution. But when implemented well, re-faced applications can last far longer, especially if you can bolt on additional functionality from outside the host application but integrate it seamlessly in the re-faced UI.
I’ve had a good experience with re-facing, though I’ve found it has to be used in the right situations. In a future post I’ll share some thoughts on getting the most out of your next re-facing project.