Software Modernization

Semantic Designs provides tools and services
to help manage the modernization and evolution of legacy systems.

Running legacy software systems are worth their weight in gold.
Such software runs companies, and usually cannot simply dropped.

These systems are successful and therefore mature, and likely have
been in existence for a long period of time. A consequence
is that legacy software is built using technologies available
at the time it was constructed, as opposed to the most modern
software technologies. Older technologies are more difficult
to maintain, and this is a key point of pain for many legacy system owners.

Upgrading the software to use more modern technologies
is often a critical need. Typical approaches include
rewriting from scratch, replacing with COTs,
or modernizing the legacy code itself. Rewriting and
COTS replacements are usually much less successful than code modernization.
(For background on risks with the various approaches based on experience, see this
Standish Group White Paper "Modernization: Clearing a Pathway to Success").

Sometimes the software must actually
be converted to another language, but Software (Language) Migration
is discussed elsewhere.
It is often the case that an application may need restructuring
to meet other business goals. That topic is explored in more
detail elsewhere on this website. Here our attention is focused
on managing the legacy technology.

Modernization Tasks

There are a variety of different modernization tasks that one might consider, individually and in combination:

GUIs/Webification. Commonly legacy green screen terminals need replacement and a GUI or a web-style interface is desired. This requires location of all the screen management code across the system and replacement with equivalent functionality with new display technology.

Switching to Relational Databases. Legacy systems may use flat files or hierarchical indexed databases. Better integration with the rest of organization, and easier code changes leading to better business response can occur if the legacy databases are replaced with relational databases.
The legacy data models must be converted to new relational schemas, sometime with reorganization. The legacy data must be moved into the new relational schema, and often there is need to clean the data as it is moved. Finally, one must find all the database accesses, and translate them from the legacy style/data model to SQL calls with the new data model.

Lift-and-shift. It may be the Operating System (or computer on which it is based) is the largest legacy hurdle, and the application needs to be moved from the legacy OS to a more modern one, such as Windows, Linux, or AIX. One must find and replace all the OS-dependent calls (file I/O, screen management, security) present in the code, and sometimes to change source code idioms due to differences in language dialects between the legacy OS and the modern OS.

SOAization. One of the principal values of a system is the data it stores, and the set of services it effectively provides. Legacy systems often do not provide any external access to those services and data. One must locate the data accesses and the services (e.g., the business logic behind the screens) that are useful, and expose those data accesses and services as APIs or web-based interfaces.

Rearchitecting. It is common that the architecture of the software has decayed since inception, and/or that it needs to be reorganized to isolate the business logic from the data access and the screen I/O. The architecture principles must be defined, the code must be classified as to which architecture purpose it serves, new architecture layers and interfaces must be introduced, and the now-classified code must be moved to the appropriate architectural layer without breaking the application functionality.

Automated Test Case Construction/Execution. A key problem with maintaing any large system that is undergoing continuous evolution is verification that the sstem continues to function correctly after a change. Most organizations are woefully short on automated tests for the application functionality, which limits the business rate of change and lowers the reliablity of the result. One needs to construct a standard mechanism for unit- and system- testing, and create tests for existing functionality to enable repeatable regression testing.

For large scale systems, all of the above tasks are extremely difficult, expensive and long to accomplish by manual methods. Most attempts to do these activities by hand end badly for the team doing the work, and the company having the work done.
What is needed are tools to accomplish the tasks. It is, however, an unfortunate fact that there is no market for tools needed for the specific combinations of languages and technologies which make up your system, so these cannot be found as COTS. What is needed is a way to build the needed tools rapidly and reliably, and that is what SD provides with the DMS Software Reengineering Toolkit.

Related to modernization is analysis to help focus attention on parts of the software or to achieve understanding.:

Finding functionality. To change something, it must first be found. In a large software system, the functionality of interest may be scattered across many modules. Functionality may be located by using a Source Code Search Engine, or Test Coverage Tools.

Architecture Extraction. To make massive changes, it is important to have a good high-level view of how the software is organized, e.g., the software architecture. This may include Component Connectivity and/or Call Graphs.

Test Quality Analysis. Before one starts a large modernization task, it is important to understand what is known about the functionality of the existing system. Such functionality is effectively only represented in the automated tests that can be run. A Test Coverage Tool can be used to evaluate how well tested the existing software is, and how effective the automated tests are, and can be used to evaluate the final modernized system.

Code Quality Analysis. One way to gauge costs is to measure code properties such as Metrics or code Clone Detection, or using static analysis tools.
ages and development tools needed to support the legacy system are increasingly difficult or expensive to obtain. This is a very common occurence with 4GLs popular in the 1970s.

To discuss modernizations in more detail,
contact us. Details about timeframe, the set of legacy technologies
to upgrade and the langauges using them, and desired modern technologies are extremely helpful.

Topics

Semantic Designs- Our Goal

To enable our customers to produce and maintain timely, robust and economical software by providing world-class Software Engineering tools using deep language and problem knowledge with high degrees of automation.