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.
See a discussion of issues for manual versus automated tooling for modernization.
Semantic Designs can help your organization assess and plan a modernization project using highly automated tools, thus controlling quality, cost, and timeframe.
SD's generalized compiler technology, The DMS™ Software Reengineering Toolkit provides a proven foundation for implementing such custom tools. DMS can handle multiple source and target languages, and scales to handle systems with millions of lines of code. SD's existing library of standard language front-ends for DMS significantly minimizes the cost of building such tools.
Assessment and Planning
Any large migration requires careful planning and support. Semantic Designs can
- define an effective, economical porting plan which minimizes risk
- carry out automated assessments of a source code base for troublesome constructs
- design reliable translations for each source construct or API call
- provide tools to help determine how well the converted application has been tested.
See the C++ Component Model Reengineering By Automatic Transformation article from the May 2005 issue of CrossTalk - The Journal of Defense Software Engineering describing a project done with Boeing.
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.
