Having considered the reasons for modernization, and having some idea of the ideal target architecture, it's time to consider what tools can be used to assist in this process. Some types of tooling that may be worth considering include:
Rehosting and Replatforming Solutions
These solutions allow you to run old code on new(er) infrastructure with minimal changes.
- May be appropriate for extending supportability of applications nearing end of life
- Can provide cost savings by allowing expensive mainframe infrastructure to be sundowned
- Does not address many of the legacy issues discussed above
Discovery and Documentation Tools
Discover and (to some extent) reverse engineer existing systems.
- Useful for generating inventory of existing application capabilities and logic as a starting point for transformation efforts
- Can identify dependencies, issues and in some cases estimate costs to modernize various application components
- Cannot provide prioritization of features required in the transformed state
- E.g. IBM Transformation Advisor for WebSphere J2EE apps
API Frameworks
Allow you to expose legacy applications’ data and logic in the form of modern APIs.
- These tools are frequently used to develop the “facade” component of the “Strangler” pattern for legacy transformation
- Can aggregate legacy and new application features into a single API for downstream applications
- Some also provide API management features (e.g. security, monetization and throttling) to allow APIs to be exposed to 3rd parties securely)
Low Code Platforms
Empower business users and legacy developers to build modern applications.
- Use the people who know the business without having to learn all of the skills required to build full-stack web applications from scratch.
- Allow for innovation and redesign as a part of the transformation process
- Support a culture of ongoing improvement
Robotic Process Automation
Allows creation of bots to simulate user actions to interact with legacy systems.
- RPA can be used as a band-aid solution for dealing with legacy applications without replacing them
- RPA can give localized productivity improvements, but larger transformation efforts typically require some kind of process orchestration to link bot activities with API calls and human interactions
Some of these tools can be packaged up into larger offerings, for example IBM offers the Cloud Pak® for Applications includes the Transformation Advisor tool, as well as accelerators for cloud-native development, and RedHat Openshift to help companies make the jump to a container on cloud architecture.
Using the Loopback API Framework for Legacy Transformation
What is Loopback?
Loopback is a highly extensible Node.js and TypeScript framework for building APIs and microservices. The LoopBack framework is built on top of Express, the most popular Node.js package for web server development. Its lightweight, extensible, and flexible nature makes Express a perfect fit for projects, small and large, from simple websites to complex web frameworks. Loopback comes packed with tools, features, and capabilities that enables rapid API and microservices development on Express, and provides for easy maintenance. LoopBack is an open source project backed by IBM and used by IBM products and customers, which gives some assurance on the quality and the longevity of this framework. Check out loopback.io for more information.
Node.js is an asynchronous event-driven JavaScript runtime, designed to build scalable network applications. Javascript has been the most commonly used programming language for almost a decade, and Node.js is used by a lot of developers, and perhaps equally importantly, a lot of younger developers. For these reasons, Node.js is rapidly increasing in popularity in the enterprise, as a low cost way to build and maintain applications. Node.js is open source, used by millions of developers, with over a million packages available on Node Package Manager (npmjs.org). Learn more at nodejs.org.
Technical Details
LoopBack implements the model-view-controller (MVC) pattern. The models are defined in model files, controllers provide the REST API interface, and views are JSON objects returned by the controller. This not only allows modular development of the project, but also prevents the codebase from getting messy and unmanageable as the project grows.
Loopback uses the repository pattern to abstract data access logic including connections and queries from the models. It uses the OpenAPI specification for describing the request and response formats. LoopBack exposes an OpenAPI specification file created out of the controllers in the app, which is essentially the documentation of the whole REST API of the app.
Configuring database connectivity and executing queries is one of the most crucial tasks when developing APIs. With the numerous database options available, writing optimal queries, and maybe even switching to a different database altogether can become a very tedious and time-consuming task.
LoopBack provides an abstraction for database access using datasources. All you have to do is select the database you want to use for your app and provide the connectivity details. LoopBack then takes care of making the connection and running the queries in the context of a REST API implementation.
Any time you want to switch to a different database, it is just a matter of specifying a new datasource. You don’t have to worry about re-writing the queries, LoopBack takes care of it for you.
We built Apex Designer to have a simple GUI for defining business objects and relationships which then generates the Loopback API for a project. Apex Designer also builds Angular front-ends, and we use it in many of our projects. For simple projects you can build a complete API in minutes without writing any code. However the extensibility of Loopback is maintained, so that for more complex projects, you can define object behaviors, custom API endpoints, and anything else you might need.
Compatibility
With the technical details taken care of, let's consider compatibility of Loopback with our legacy transformation project.
Supported database datasources:
- In-memory db
- In-memory key-value
- IBM Object Storage
- IBM Db2 (for Linux, Unix, Windows)
- IBM Db2 for i
- IBM Db2 for z/OS
- IBM DashDB
- IBM MQ Light
- IBM Cloudant DB
- Couchdb 2.x
- IBM WebSphere eXtreme Scale key-value
- Cassandra
- gRPC
- Redis
- MongoDB
- MySQL
- PostgreSQL
- OracleDB
- Microsoft SQL
- z/OS Connect Enterprise Edition.
Supported non-database datasources:
- OpenAPI
- REST services
- SOAP webservices
- ElasticSearch.
Community supported datasources include:
- Couchbase
- Neo4j
- Twilio
- Kafka
- SAP HANA
Loopback gives us the ability to mix and match datasources and provide a unified API to applications and clients. This powerful capability can be used to support legacy transformation projects in several ways, best illustrated with a few examples.
Case Studies
Tactical Modernization of Timekeeping System
We worked with a client that was undergoing a merger and needed to bring new users onto a legacy time-keeping system. The legacy mainframe system was written in COBOL with an IBM DB2 database and used a green-screen UI. Management were concerned about the viability of training new users from the acquired company to use it. The system was also earmarked for replacement, possibly with a commercial product in the not too distant future. A tactical solution was needed to provide a user-friendly web interface to the legacy system.
We used Apex Designer and Loopback to rapidly build a REST API that communicated with the DB2 database, along with an Angular web application for users to access the system. Although connecting to the DB2 datasource was relatively straightforward, of course there was plenty of undocumented business logic embedded in the COBOL program. The Loopback API was extended with customizations to replicate the business logic of the old system. For example, checks were added to ensure users were not accidentally “clocked-in” overnight by comparing dates on clock-in events.
With the API and web application in place, the client was ready to replace the legacy mainframe database with a modern database (e.g. SQL Server) by simply changing the Loopback datasource.
Application Synchronization With Loopback
Another strategy for legacy modernization is using data synchronization to add new capabilities on a modern platform, based on master data coming from a legacy platform. With inbuilt capabilities for different datasource connections, Loopback is ideally suited for building this type of synchronizer.
A client project required synchronization of data between a legacy DB2/I-Series application and a new node.js / SQL Server application. The legacy functionality was redesigned in the new application for usability and to provide additional features. Using Apex Designer and Loopback, we built a sync application. Over 10m records were copied overnight in the initial load. We were able to add logic to the application, for example normalizing address data against a 3rd party address validator. Subsequently, updates were synchronized in real time (approximately 5ms per record, including normalization).
Conclusions
The Loopback framework is a powerful tool for API development, and has several features that make it highly applicable to legacy modernization scenarios. Apex Designer adds a GUI to the model-based approach inherent to Loopback, making API creation even faster and easier. We have successfully applied these tools in several legacy modernization projects. To find out more, contact us.
