Existing legacy integration tools and methodologies are based on the 20-year-old concept of turning relevant pieces of legacy code into services. However, for many underappreciated reasons, “service-oriented” integration imposes heavy constraints and limitations that yield to less than ideal business processes.
Enterprises have launched their most strategic process in decades without realizing that they have an inappropriate toolset at their disposal.
Legacy Integration Solutions Do It Wrong
Legacy systems are based on two interrelated principles:
1. They are procedural.
They are built of programs structured as a top-down set of procedures (also known as subroutines or functions). A procedure is a (long) linear list of statements. An application’s internal data model typically reflects a database structure rather than business objects. The procedures and the data are treated as separate entities.
Business and database transactions very often are spread out over a long and tangled web of difficult-to-follow code. An attempt to restructure the code or access a part of it may easily end up harming data integrity.
2. They are stateful.
Data used by the procedural programs is saved and accessible by their procedures, along with the entire user session.
Validations, calculations, and data manipulation depend on cumulative data, collected or computed in earlier steps of the application execution.
Many legacy systems to expedite performance and facilitate programming load a large set of constant data during application initialization and use it throughout execution.
The database connection is usually established upon application launch and closed on exit.
Nevertheless, modern tools and methodologies insist that legacy modernization and digital transformation should be based on wrapping pieces of legacy code into services: “SOA,” “Web Services,” “Micro-Services,” “Services via API,” etc. In other words, turning stateful, procedural programs into stateless, object-oriented classes. . .
Services libraries typically provide one of the two types of services:
1. Expose data selected and manipulated by the legacy system.
2. Process some business logic.
Wrapping legacy code into a stable library of services is a complex, long, and expensive process that requires a wide skillset of both business subject-matter expertise, as well as modern technologies experts.
Due to the complexity of identifying isolated pieces in the legacy system, very often the minimal feasible granularity of such a service is an entire business transaction.
The dependency on services’ availability and granularity makes it practically impossible to build a reasonable human interface without writing a significant amount of redundant code.
The need to capture and process all preliminary code and data in every stateless service usually has a severe effect on performance.
Consequently, core business process digitalization becomes the development of brand-new applications that at a few points extract data from legacy systems and (many times only at the end of the business process) call business logic processing services. Such behavior contradicts the most fundamental UX principles.
In summary, service-oriented legacy integration is risky, long, and costly. Most importantly, it imposes severe limitations on the quality of the resulting digital application.
There is a Right Way
Mosaics offers a revolutionary alternative.
After some minor, one-time adjustments to the specific legacy application, Mosaics automatically peels off the code that interacts with the exiting screens (i.e., what users see and how they can enter input). It then replaces it with an interface that can communicate with Mosaics’ task driven human interface. The human interface can provide the input expected by the legacy program to smoothly execute the existing business logic.
This turns the entire legacy application, at once, into a set of journeys. With the appropriate input, these journeys can lead the execution of every single piece of the entire application—from end-to-end.
Mosaics assigns each digital user session a dedicated, stateful connection to the “journey-driven” version of the legacy application.
The legacy code can be called at as many points as needed, even at the smallest granularity. Each call executes a part of the collective set of paths required to perform the relevant business task in the legacy system.
Sequences of steps that do not require any user discretion run automatically without any user intervention (“behind the screens” robotic process automation).
The integration process consists of defining the journeys and attaching them to the right places along the digital interface. The analysis is done by running the existing legacy system (as users, not as programmers) and documenting the paths and input required to complete the business task.
Obviously, this must be handled carefully and takes time. However, unlike any other applicable alternatives, it does not require any code analysis and restructuring. The process is in order of magnitude less complex, significantly faster, and requires less testing and maintenance.
Ongoing development and maintenance of the legacy system continue just as usual, by the same team and according to the same development practice.
Performance is optimal, and there is no need for any redundant development.
And the most disruptive benefit? Mosaics can design and generate the optimal digital interface that perfectly reflects the way users should do their work without any limitations imposed by the existing application or underlying technologies. Once the digital interface has been proven to be optimal, it can be smoothly integrated with the “journey-driven” version of the legacy application.