Modernization of Application Business Logic
Today, legacy modernization initiatives are everywhere. The need to modernize systems in order to transform businesses is often a requirement, and the stakes can be high. An enterprise may feel extreme business pressure to operate like its smaller more agile competitors. Getting to that agile “state” can be a huge endeavor when a 7-10+ year old legacy system has to be modernized as part of the process. There are a number of companies offering products, services and methodologies related to legacy modernization. I’ve added some links to resources at the end of this post.
System Code by Yuri Sumoilov (CC BY 2.0)
Modernizing a legacy application might include many facets – modernizing the user interface, architecture, API, database, and core business logic. In this post, I’m going to focus on one aspect of modernization – recreating core business logic in a new system or service.
You can think of “core business logic” as the decisions that a system makes as it processes transactions. For example, the core business logic of a legacy insurance underwriting application, might include decisions such as whether or not the applicant is eligible for coverage, what is the level of risk, whether to approve, deny or refer, and what to charge for premiums. Modernization of those decisions would involve a recreation of the business logic that’s in the legacy system. But on a modern, agile platform that can meet today’s business needs.
According to James Taylor, from Decision Management Solutions, “ By focusing on the decisions represented in the core business logic you are likely addressing the most costly to maintain aspect of a legacy system. Decision-making is often high-change with new regulations, new policies, competitive response and evolving consumer/market conditions driving a need to make changes. For example, the way a fee is calculated, the way an application is validated, the way a claim is checked for eligibility – these kinds of decisions, hidden in the core business logic of legacy systems, result in big maintenance bills and long periods where the system works incorrectly or inconsistently with the business need.”
With a focus on the core business logic, how do you approach modernization?
Code Conversion Legacy Modernization Approach
Often, for modernizing business logic functionality, organizations, and their consulting partners, will take a “code-focused” approach. Using various tools, the migration is accomplished by assessing the legacy software code, analyzing and uncovering core business logic, applying conversion tools to create modernized code, and finally, testing for functionality and errors.
Code Conversion – Limitations
Although this is a viable way to approach the modernization of business logic, it has two significant limitations:
Today’s platforms are different
Older system architectures are less functionally modular than today’s microservice architectures. Most legacy systems were built as monolithic applications or client-server systems. The business logic in these systems was likely based upon procedural or object-oriented design and scattered throughout functions or methods in COBOL, C, or C++ code. (Yes, today some systems developed in “modern languages” like Java and C++ are now considered legacy!) The concept of organizing business logic around decisions and services simply did not exist when these applications were developed.
Today’s preferred approach to core business logic is to define decisions in a decision management platform, where the decision rules will be organized according to how the enterprise thinks of the business problem. Decisions are then deployed to a decision service and integrated into modern architectures through a REST API.
Legacy systems weren’t built for change
The legacy system has undoubtedly been enhanced a number of times over an extended period – incrementally. By incrementally, I mean that changes made to the legacy system were based on the delta between the system in its then current state, and some new functionality that more accurately reflected what the business needs were at that time.
If a legacy system had been in use for, say, a 7-year period, with 2 incremental updates per year, those 14 incremental changes in functionality were always constrained by the systems previous state. Legacy systems simply weren’t built to support change and provide the ability to change in unexpected ways.
The result is that the code inside these legacy applications is complex – more complex than if it was built from scratch to have the same functionality it has today. It’s not just spaghetti code- it’s spaghetti on top of spaghetti! Converting that functionality to a modern platform using code-conversion tools alone can bring all the extra, unneeded complexity into the new platform.
Decision Management – Data-Driven Legacy Modernization Approach
Today’s modern decision management platforms use data and analytics to enable the process of improving operational decisions. Looking at historical results from the legacy system, adjusting rules inside a decision, and then running tests comparing the results, is an effective way to transform legacy business logic into modern decision services.
Using insurance underwriting as an example, you could look at the applicants that were approved by the legacy system (i.e. legacy system historical results) and compare them to the applicants that would be approved using a baseline set of business rules in a decision management system. Analyzing mismatches between the two sets of results could drive the discovery of which rules are missing or need to be adjusted to produce matching results.
For example, you might discover that 25% of the differences in approval status are due to differences in risk level. This insight leads you to focus on adding and/or modifying your risk related rules. Once the legacy code and the rules are assigning the same risk level, the overall mismatches have been reduced by 25%. Repeating this analyze-improve step will reduce your mismatches until the results from the modernized business logic exactly match those from the legacy system.
Decision Management – Benefits
The modernized business logic, expressed as business rules in a decision management platform, doesn’t follow the complex path of how the legacy system was created or updated over years; but it does get the same results. It’s a simpler, and easier to maintain and extend, representation of the business logic.
Also, using a decision management platform to hold and maintain the modernized business logic brings with it the standard agility benefits of decision management:
- Easy to change
- Understood and often managed by Business Analysts
- Change management control through versions and releases
- Highly scalable deployment
Summary and Resources
Using this “data-driven” approach to recreate the core business logic of a legacy system on a modernized platform can complement, and in many cases, replace a code conversion approach to modernization. At a minimum, in the large and complex world of legacy modernization, it can be an important part of the toolkit and methodology to achieve success.
Below, I’ve listed some resources for legacy modernization, and some for Decision Management. Please let me know about others we should include.
Legacy Modernization Resources:
- Software Modernization: https://en.wikipedia.org/wiki/Software_modernization
- Approaches to application modernization: http://www.mrc-productivity.com/blog/2012/04/5-approaches-to-application-modernization/
Decision Management Resources:
- Sparkling Logic SMARTS Decision Manager
- Legacy modernization with decision management: http://www.slideshare.net/jamet123/legacy-modernization-with-decision-management-and-business-rules
- White Paper: Simplify Legacy Modernization with Decision Management: http://www.decisionmanagementsolutions.com/whitepaper/simplify-legacy-modernization-with-decision-management/
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
