Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


When It Comes to Legacy Systems, It’s Hip to Be Square

By William Mooney, Posted on September 16, 2021 at 11:34 am

Avatar

I talk to a lot of CEOs, CIOs, and CTOs who feel pressured to replace legacy (aka proven) applications that have served their multibillion-dollar organizations faithfully for 30 or 40 years or more, in a quest for “modernization.” My advice, more now than ever, is never touch a hot stove, and please don’t burn your house down.

While CEOs tend to have a longer lifespan, I’ve seen a great many CIOs and CTOs come and go because they got burned by an ill-thought-out move toward IT modernization and because, in some cases, they figuratively burned down the house, bringing line-of-business applications to their knees and significantly impacting operations—leaving it to their successors to beat a hasty retreat back to the rock-solid legacy systems that some see as old-fashioned.

Some say it’s a build versus buy question. I say it’s a built versus buy question: those legacy applications are already built and running. Yet I’ve encountered C-level executives who just two months after joining a company have made hasty—turned disastrous—decisions to throw out the old in pursuit of the new. But they’re trying to solve a problem that doesn’t really exist. Well, kind of. Yes, there are known issues and problems. However, companies typically don’t invest in solving these known issues and problems and instead kick the can down the road. Then the new CxO comes in and suddenly gets the green light to make the investment, and money that never existed before is now abundant.

Migrate your code to a new platform? Definitely. For years companies have been moving their legacy systems from OpenVMS, IBM AS/400 and AIX, Sun boxes, and other systems onto Windows or Linux, while retaining the original code of their legacy applications.

Apply a modern user interface? Go for it! With browser-based, Windows-desktop, and mobile front ends, you can change the UI at any time, without endangering the line-of-business legacy code that has kept your business prospering for decades, and you can continue to do so for decades to come.

Replicate your legacy data to a modern database? Absolutely. While preserving your existing data and logic, you also make your data available for ETL processing into a data warehouse or whatever other BI environment you choose.

Use modern development tools? Of course. Armed with the right tools, which a good developer can learn quickly, you can take advantage of the myriad developer productivity, code quality, and other features that are inherently present in modern IDEs like Microsoft Visual Studio. Your legacy application being written in DBL, COBOL, BASIC, or the like does not prevent you from using modern tools and development techniques.

It’s Hip to Be Square

When it comes to retaining your bullet-proof legacy systems that have supported your business for decades, I encourage you to have a new appreciation for the steadfastness of DBL, COBOL, and other legacy languages. As the musician Huey Lewis sings, “It’s hip to be square.” When it comes to stability, DBL, COBOL, and the like rock—as in rock solid.

In celebration of COBOL’s 60th birthday in 2019, Mike Madden posted an appreciation titled “Happy Birthday Dear COBOL,” which presented these figures:

• COBOL supports 90% of Fortune 500 business systems daily

• 70% of all critical business logic is written in COBOL

• COBOL connects 500 million mobile phone users daily

• 95% of ATM transactions pass through COBOL code

• 80% of all point-of-sale transactions rely on COBOL

• There are more COBOL transactions executed daily than Google and YouTube searches

• 1.5 million new lines of COBOL code are written every day

• 2 million people work in COBOL

Yet within the industry, there’s a tendency to judge a book by its cover, to see a green screen and cringe, and to risk one’s career by saying, “We’re going to rewrite that application to bring it into the modern era.”

Upon such statements, careers have faltered and business continuity has foundered.

Too often lost in a rush toward the new is the simple fact that you can apply a modern user interface to your legacy application’s code base, usually in a fraction of the time and at a fraction of the cost of replacing the application with something else.

One of the main techniques for enabling this type of enhancement is to create a “services layer” between your legacy code and your new UI. Usually this involves building RESTful web services APIs that expose your application’s business logic and data through modern, flexible, open, and secure protocols.

Once you have this services layer in place, it can be used by any new UI that you choose to build, using whatever tools you decide to use. But be extremely cautious about trying to rewrite the back-end code that has been reliably supporting your business operations, perhaps for decades.

Question: Do you think you can rewrite 35 years of customized applications in three years? Quick answer: No. I’m sure your business applications have been steadily upgraded and customized over the years, involving a vast number of accumulated developer hours. The nuances in that code should be considered your secret sauce. Could it be duplicated in C# or some other language? Yes—but not within a timeframe, cost, or risk profile that most organizations would want to take on.

Gap Analysis: 2 or 3 Years

In the classic American western Butch Cassidy and the Sundance Kid, the two outlaws have been tracked down by a posse. They’re at the edge of a cliff with nowhere to go except a very rough river far below. As Butch tries to talk the Sundance Kid into jumping off the cliff to the river below, Sundance finally confesses: “I can’t swim!” Butch laughs and says, “Are you crazy? The fall will probably kill you.”

That scene comes to mind when considering the essential task of performing a thorough gap analysis before trying to replicate the old legacy code that you think needs to be replaced. Just the gap analysis can take two to three years. That’s the jump. But attempting to create a new application without a gap analysis—using a needs-based approach—is equivalent to the other fate: facing certain death.

When I speak of the “secret sauce” incorporated into your legacy applications over the decades, I’m not talking about something basic like general ledger, accounts payable, or accounts receivable. I’m referring to the more complex pieces, like order entry and inventory management, that involve intricate orchestrations, workflows, and in-depth business knowledge.

For example, we worked with a company that has long provided DIBOL-based software for tracking grain in storage. That might sound simple enough, but the workflows are complex. Looking at just a subset of the tracked elements: upon arrival, the grain is measured for weight, of course, but also for moisture content, which feeds an algorithm to determine yield and value of the grain. Next, the grain is mixed with other grain in silos where it may sit for months or years, and it is tracked as it transfers from one silo to another for shipment. All along the way, there are elements and dependencies worked into the code that could take some years to identify through gap analysis, even before any actual coding starts.

We’ve seen supposed three-year modernization projects drag on for more than a decade, with still no end in sight. And there was no actual need to replace the application: other options were available that would have addressed the requirements more quickly and at a significantly lower cost. The new CxO just felt compelled to replace the application with something “modern.”

But Who Does Legacy?

A common fear is “But I can’t hire old-school developers!”

Any good developer that you hire out of a computer science program, given appropriate time and support, will learn both your environment and the language that you use. Of course, developing in a modern IDE can only help to accelerate that process. Good programmers adapt to a new language quickly.

The real question should be “Who has the business knowledge?”

What generally takes much more time for a new hire to learn is the specifics of your industry, and that learning challenge applies to all developers. This “domain knowledge” about your industry is what your legacy application has wrapped up in its code: decades of carefully acquired and crafted business logic. It’s not hard to find someone who codes. But try to find someone who knows grain elevators inside and out. Or who knows your international shipping regulations, practices, and requirements. Or your consumer-packaged goods business. Or life and casualty insurance. Those legacy systems are vast storehouses of carefully acquired wisdom, set into code as business logic.

You can put an attractive front end (and please do) on anything, through the use of web services and other modern technologies. But it could take years, perhaps decades, to capture and recast the real-life business logic sitting in that legacy code. So the next time someone suggests a multi-year modernization project, just smile and remind them: Sometimes it’s hip to be square.


Announcing Synergy 12.0

By Steve Ives, Posted on September 10, 2021 at 2:48 pm

Steve Ives

For the last several months the Synergy development team has been building out the features and functionality for the next version of Synergy, including the not-insignificant task of adding support for Microsoft .NET (in addition to .NET Framework) throughout the product. We are now ready to start sharing some of that work with you.

Some of you may have noticed something slightly unusual in the title of this announcement; the version number includes an even number! The complete version number of the release is 12.0.1.3272, which is also somewhat different from previous releases. We have implemented a new release strategy involving two types of releases: Long-Term Support (LTS) Releases and Feature Releases. You can find more information about that on the Synergex website.

Synergy 12.0 is a feature release, providing early access to some of the features and enhancements that will be part of the Synergy 12.1 LTS release later this year.

IMPORTANT: In this document and in other places, the term .NET refers to Microsoft .NET 5 and higher, while the term .NET Framework refers to the original .NET Framework product through its final 4.8 version. The term .NET Core refers to the interim product which culminated with a final 3.1 release.

Primary Focus of this Release

As previously announced, the primary focus of our current development is to add support for Microsoft .NET, and in some cases .NET Core, in all the places in Synergy where .NET Framework is currently supported. Some of these changes are being shipped for the first time in this release, while others will follow in subsequent 12.0 feature releases. Not all of the included changes are related to .NET; there are changes throughout the product set, as detailed below.

New Features and Enhancements

This section presents information about new features and enhancements included in this release:

.NET Support for Synergy APIs and Utilities

Several Synergy libraries and tools are now available as NuGet packages and provide support for .NET:

Library                     NuGet Package Name
Gennet Utility              Synergex.SynergyDE.gennet
Repository API Library      Synergex.SynergyDE.ddlib
UI Toolkit Library          Synergex.SynergyDE.tklib
XML API Library             Synergex.SynergyDE.synxml
xfNetLink .NET Library      Synergex.SynergyDE.xfnlnet

xfNetLink .NET

In addition to the Windows installer package, the xfNetLink .NET library is also now distributed as a NuGet package. The NuGet version of the library is built with .NET Standard 2.0 and so is usable from .NET Framework 4.7.2 and higher, .NET Core 3.1, and .NET 5 and higher environments.

The gencs utility now generates a C# project file that you can use with Visual Studio, MSBuild, or the dotnet build utility to build a client assembly. Note also that gencs no longer creates a strong-name key file by default; if you rely on this feature, you must explicitly specify a key file via the gencs -s option.

In .NET Framework applications, configuration settings were usually set in configuration files, but this is not supported with .NET Core or .NET applications. To address this, we have added several new environment variables that can be used to specify configuration settings in all environments. Refer to the release notes and documentation for a list of the new environment variables.

The COM+ pooling mechanism supported with .NET Framework is not available for .NET Core or .NET applications. As an alternative, we provide a pooling mechanism that can be implemented within your application, similar to the way that pooling worked with xfNetLink Java. For additional information refer to the Microsoft documentation for ObjectPool and use the BlockingPooledObjectPolicy class that we provide in an assembly within the NuGet package.

Synergy .NET assembly API

We added support for using the Synergy .NET assembly API in .NET Core and .NET environments, in addition to the current .NET Framework support.

The gennet40 utility continues to produce code for .NET Framework, and in addition, a new gennet utility is available from NuGet as a .NET global tool (Synergex.SynergyDE.gennet). This utility produces code for the version of .NET Core or .NET in which it is running.

Synergy Runtime Enhancements

We have added platform support for Windows 11 and Windows Server 2022 and new identifiers to allow for conditional compilation based on these new platforms.

The Synergy windowing API is now available in .NET environments.

On Windows, the data encryption routines (DATA_ENCRYPT, DATA_DECRYPT, and DATA_SALTIV) now use the Windows “Cryptography API: Next Generation” (CNG) instead of OpenSSL.

Related to our version numbering scheme changes, XCALL VERSN and %VERSN now have an optional second parameter that returns the Synergy build number.

On Linux, Synergy no longer has a dependency on the libtinfo.so.5 libraries.

Synergy DBMS Utilities

Continuing with our recent theme of improving performance when accessing ISAM files, or undertaking routine file maintenance or recovery operations, more enhancements have been made to the isutl utility that can result in performance improvements in some cases, particularly when processing very large files. Refer to the release notes for additional information.

License Manager

Linux systems can now be optionally configured to forward licensing requests to a Synergy license server on a Windows system, using TCP/IP communication. This is only supported when the license server hosts subscription licenses, and note that Linux system(s) will share the same pool of license keys available to Windows clients. Amongst several benefits is the simplification of Synergy deployment on Linux to virtualized or containerized environments, including deployment in cloud-based scenarios.

If you wish to implement IP-based licensing with existing Linux systems, you will need to work with Synergex Customer Service, as they will need to consolidate any existing Linux licenses into Windows licenses, and you will have to reset and reconfigure licensing on your Linux systems.

We have improved license server operation on UNIX and Linux systems to simplify running the license server under a non-root user account. Specifically, if file permissions prevent the license file from being written to the /usr/lib directory, it will now be written to /var/synergy instead. Additionally, if the license file is in /var/synergy, the location of the license server log file will default to the same location.

Quality Improvements

As usual, in addition to the new features and enhancements detailed here, Synergy 12.0 includes quality improvements throughout the product set. Again, refer to the release notes for complete information.

Documentation and Downloads

Documentation for feature releases will be available online only at https://www.synergex.com/docs. This website will always default to displaying the documentation for the current LTS release, but until Synergy 12.1 is released, the current default is the 11.1 documentation. To view the updated documentation for the 12.0 release, be sure to select “12.0 (feature release)” from the version dropdown.

In addition, the release notes that document everything that changed in this release can be viewed in the product downloads area of the Synergex Resource Center. Similar to the documentation, the downloads area defaults to displaying the latest LTS release, and currently defaults to displaying the 11.1 downloads. Click on the prominent red “Feature Release” button to view the downloads and release notes for the feature release.

What About SDI?

Synergy DBL Integration for Visual Studio now follows a separate development timeline and release cycle, and releases may not coincide with SDE. The SDI team has been hard at work, and you can expect an SDI release that supports Visual Studio 2019 and the upcoming Visual Studio 2022 very soon.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives