How to streamline your legacy modernization efforts with app refactoring
The concept of legacy application modernization has evolved over the past 15 years. In the early 2000s, legacy transformation meant replacing the custom-built core enterprise systems running on mainframes or AS/400 systems written in programming languages such as COBOL, Rexx, or IBM RPG with pre-packaged software from the likes of SAP or Oracle to suit the changing business needs.
Enterprise mobility brought in a new paradigm wherein all enterprise applications—custom-built or purchased, core or otherwise—needed to be made mobile-friendly. Through modernization, today’s organisations are looking at making their monolithic and inflexible legacy systems ready for the competitive landscape, new business processes, standards, customer needs, and regulations while offering seamless user experience across mobile devices.
The evolving approaches
Traditionally, an enterprise software system comprises five layers: Core Business Logic, Database Layer, Data Access Layer, Exposure Layer (or SOA Layer), and Presentation Layer. In addition, the tools for data storage and analysis such as ETL are part of the software ecosystem. Application modernization efforts generally involve creating a new API Layer between the Exposure Layer and the Presentation Layer. This approach has evolved from the traditional methods that focused on Database Layer, Data Access Layer, and ETL.
Traditional legacy modernisation methods were expensive, time-consuming, and tedious. These involved multiple complex tasks such as migration of programming languages, databases, platforms, rewriting legacy code for a new platform, re-hosting, and replacement. The API led legacy modernisation began to be seen as a better method as it avoided multiple challenges the older methods were beset with. Deemed as non-disruptive, API enablement improved the integration possibilities, eliminated the need for rewriting the code, and helped enhance the cloud readiness of the organisation.
Issues with API enablement
Although a better option than the older methods, even API enablement is a time-consuming process. API developers have to carefully connect to data sources, and apply business rules and validations. To illustrate with an example, consider the scenario of building an app for a suppliers portal. In this case, a user can either be a vendor or buyer—the information access rules are different for both. If a buyer logs in, he should be able to see multiple vendors. But if a vendor logs in, he should see only his homepage. The vendor’s homepage may have details such as open tenders, his current orders, delivery and credit terms, invoice and tax deduction updates, payment information, and past orders.
An API developer needs to protect the sanctity of business logic while designing APIs for such an app. No supplier, for instance, should be able to view confidential business details of any other supplier. In effect, API building is not just about connecting to the data sources. The bigger challenge is applying rules, validations, and business logic to define what data is permitted to be shown at the API endpoint. Also, there are pain points of a legacy system.
API enablement has a few other challenges too:
• Lack of a bird’s eye view of proposed APIs
• Incorporation of security measures
• API project ownership questions (shared service model or IT-owned)
• Budgetary allocation and monetisation issues
• Regulatory compliances
App refactoring: A new approach
Application modernization for mobile devices is a two-part exercise. The first part is building APIs (API enablement) and the next part is creating a suitable frontend. CTOs and CIOs who have walked this path may know that nearly 80 percent of the efforts involved in application modernization for mobile devices are related to API enablement. Only about 20 percent of efforts go into creating a customized front-end with the user interface (UI) and styling suitable for mobile platforms.
This is where a few forward-looking organisations have successfully employed a new method—app refactoring. This novel approach cuts down upon the arduous 80 percent part by shifting the intelligence-building toward the front-end creation exercise. Unlike API enablement or the older legacy modernization methods, app refactoring captures data directly from the application’s HTTP Layer or the Presentation Layer and builds a new mobile-friendly frontend.
While API enablement requires source data in formats such as JSON and XML, app refactoring can access and work on the final HTML output. The new method constitutes using best-of-breed refactoring and designing tools to capture, analyse and interpret data, employ appropriate business rules, and create a modern frontend ready for the mobile world.
A true advantage
As explained above, the new approach hugely cuts down the time and costs involved in legacy modernization for mobile. This way, a CIO can not only free up funds for his next business-impact initiatives but also demonstrate his lean management capabilities. App refactoring delivers another significant advantage. Due to its truly non-intrusive nature, it also minimizes the risks associated with the modernization methods hitherto employed by organisations. In short, a success assurance formula for a CIO’s report card.
https://computer.expressbpd.com/news/how-to-streamline-your-legacy-modernization-efforts-with-app-refactoring/23127/