Conceptual extension of the M. Fowler model in relation to the migration and modernization of distributed application interfaces

Relevance of the study

The importance of this research topic is due to the need for smooth and controlled modernization of distributed applications, which cannot always be completely replaced without the risk of disruption of their functioning. Such systems often serve many users, interact with various software services, and require stability during the update process [4, p. 121].

One of the widely known approaches to solving this problem is the Martin Fowler model, which involves the consistent replacement of outdated components with new functionality. Its use makes it possible to minimize the risks associated with a sudden transition to a new system and to monitor the modernization process at each stage.

This problem becomes especially relevant when it comes to interface systems. The user interface of modern distributed applications is not limited to displaying information only. It is closely related to user scripts, authorization, session status, error handling, and interaction with server services. Therefore, its migration requires not only the technical replacement of individual components but also the preservation of the integrity of the user experience, as noted in [2, p. 108].

Thus, the relevance of this topic is due to the need to refine the M. Fowler model in the context of migration and modernization of distributed application interface systems. The scientific significance of the research lies in developing approaches to phased user interface modernization. The practical value lies in reducing technical risks and ensuring stable application operation during the update process.

The purpose of the study

The aim of this research is to develop and validate a comprehensive model for migrating and modernizing distributed application interfaces based on M. Fowler's principles, considering specific user scenarios, routing requirements, compatibility between old and new components, application stability, and user experience preservation.

Materials and research methods

The research is based on scientific and practical works concerning M. Fowler's phased software system modernization model, micro-frontend architecture, fault-tolerant design principles, query routing, and distributed application modernization.

Methods of systematic and comparative analysis, generalization of scientific approaches, structural and functional analysis, and architectural modeling were used.

The results of the study

M. Fowler's model for software system modernization involves gradually replacing outdated components with new ones. It does not entail a complete application replacement but a phased allocation of individual functions, their transfer to a new system, and the gradual decommissioning of obsolete components. This approach reduces modernization risks as changes are introduced in stages and can be verified at each step. M. Fowler emphasizes that such gradual replacement avoids the risks associated with a complete system replacement at once [1, p. 76].

In modern software system architecture textbooks, this model is considered a method for gradual migration of outdated applications [5, p. 258]. The Microsoft Azure Architecture Center describes this approach as a consistent replacement of individual pieces of functionality with new applications and services until the new system completely replaces the old one. AWS also offers this template as a way to safely transition from a monolithic to a microservice architecture with minimal risk and disruption to the system [10].

The general scheme of step-by-step software modernization is shown in Figure 1.

Fig. 1. The general logic of the phased modernization of the software system (author's development)

 

The M. Fowler model assumes not a chaotic code replacement, but a controlled process of changing the system architecture, which is reflected in Table 1.

Table 1

The main elements of the M. Fowler model

Model Element	Content	Value for modernization
Highlighting replaceable functions	Identify the parts of the system that can be migrated to the new architecture	Allows you to start migration without completely stopping the application.
The intermediate layer	Directs requests to the old or new part of the system	Ensures that the old and new systems work together.
Step-by-step migration	Consistent transfer of functionality	Reduces technical and organizational risks
Checking new components	Evaluating the performance of the new part of the system before the full transition	Allows you to identify errors at an early stage.
Removing old components	Exclusion of outdated parts after the transfer is completed	Reduces the technical debt of the system

A source: author's development

 

Distributed application interface systems have their own characteristics. In such applications, the user interface is responsible not only for displaying information but also for executing scripts, navigating between sections, error handling, authorization, session status, and data exchange with multiple services. Therefore, when migrating the interface layer, it is important not only to maintain the technical functionality of the application but also not to disrupt the usual algorithm of user interaction with the system [8, p. 209].

Modern interface systems are characterized by a special approach called micro frontends. In M. Fowler's materials, they are defined as an architectural style in which individual parts of the user interface are developed and delivered independently of each other and then combined into a single application. This means that the interface of a large system can consist of many separate elements, each of which is responsible for its specific task [9].

When migrating an interface system, it is important to keep in mind that the old and new parts of the application may run simultaneously for some time. During this period, it is especially important to ensure a uniform appearance, consistency of user scenarios, compatibility of data formats, and stability of transitions between sections. If these requirements are not met, the upgrade may lead to a deterioration in the user experience, an increase in the number of errors, and complication of the system maintenance process.

The need for a conceptual expansion of the M. Fowler model is dictated by the fact that it was originally developed for phased modernization, the purpose of which is the gradual replacement of outdated functions. In this model, key importance is given to separating the old and new parts of the application, as well as using an intermediate layer to direct requests either to the old system or to new components. However, when applying this logic to interface systems, additional complexity arises. The user interface not only transmits requests but is also responsible for the sequence of user actions, the visual integrity of the application, and the stability of interaction with multiple services.

The gradual migration uses a special template that creates an additional layer between the client application, the old system, and the new one. This confirms that the transitional architecture is an integral part of the migration process. However, such a description is not sufficient for front-end systems, since the interface of a distributed application is closely related to user routes, screen status, error handling, authorization, and consistency of visual representation. Therefore, the model of M. Fowler needs to be clarified precisely in the context of the interface layer.

The expansion of the M. Fowler model is necessary not only to gradually replace outdated components but also to ensure the stability of a distributed system during the transition period. An interesting approach is that of G.K. Klyukovkin, who, in his work on the Design-for-Failure principle, considers design taking into account possible failures as an important aspect of the reliability of corporate backend systems. This approach is especially relevant for migration of front-end systems, since the old and new parts of the application have been running simultaneously for some time. The architecture should take into account possible failures, delays, routing errors, and disruptions in the interaction between components, as described in [6].

Another reason for expanding our model is the active development of micro frontends. In the works of M. Fowler, micro frontends are defined as an architectural style in which individual parts of the user interface are developed and implemented independently of each other, and then combined into a single application. This indicates that a modern interface can be a complex distributed structure rather than a single monolithic screen. Therefore, when migrating an interface system, it is necessary to take into account not only the replacement of the code but also the coordination of the interaction of individual interface modules (Table 2).

Table 2

What requires a conceptual extension of the M. Fowler model

Aspect	In the classical model	What needs to be added for front-end systems
Migration object	Legacy system functions	User scenarios, screens, routes, interface states
Transition layer	Routing requests between the old and new system	Managing transitions between old and new interface parts
Compatibility	Compatibility of functions and data	Compatibility of visual behavior, data formats, and user actions
Result control	Operability of the new function	Maintaining user experience and interface stability
Completing the migration	Decommissioning the old system	Removing outdated screens, routes, and client dependencies

A source: author's development

 

The author's extended model of migration and modernization of interface systems is based on the concept of step-by-step replacement proposed by M. Fowler, taking into account the specifics of the user interface of a distributed application. In this model, the key migration object is not a separate function of the old system, but an interface scenario – a sequence of user actions leading to a specific result: logging in, searching for data, performing an operation, submitting a form, or receiving a notification.

The extended model includes several interconnected levels (Figure 2).

Fig. 2. The author's extended migration model for interface systems

(author's development)

 

The practical logic of this model is that the simplest and safest user scenarios are considered first. Then, new interface modules are developed for them, which are connected through the routing layer. After checking stability and compatibility, migration zones are expanded to more complex scenarios. Finally, outdated screens, routes, and dependencies are removed from the system. This approach corresponds to the general idea of gradual modernization but is adapted specifically for the interface layer of a distributed application.

The migration process of the interface system begins with a thorough analysis of the current interface: user scripts, screens, routes, connections to server services, as well as authorization and error handling processes. This allows you to identify the most significant and risky areas of the application.

Next, separate migration zones are identified. It is recommended to transfer the interface in accordance with scenarios or functional blocks: login, personal account, data search, form submission, and completion of an operation. First, less complex sections are chosen that can be replaced without disrupting the entire application.

After that, we begin creating a new interface, configuring routing, and ensuring compatibility with the old system. Then, the new module is checked for key parameters: correct operation, download speed, stability of transitions and the number of errors. If all indicators turn out to be satisfactory, the migration zone is gradually expanded, and outdated screens, routes, and dependencies are decommissioned [3, p. 34].

The effectiveness of the extended model is assessed according to several groups of criteria. Technical criteria include interface stability, download speed, number of errors, correctness of data exchange, and reliability of routing between the old and new parts of the application.

Evaluating the effectiveness of the extended model should include not only checking the completeness of the transfer of interface components, but also analyzing the system's ability to maintain stability under high load. The study on the design of fault-tolerant systems, which takes into account extreme load peaks, highlights the importance of architectural solutions aimed at maintaining operability with a sharp increase in the number of requests. For front-end migration, this means that you need to control the download speed, the number of errors, the availability of new modules, and the stability of user scripts. These aspects are key to ensuring the smooth operation of the system under high load conditions [7, p. 46].

User criteria include maintaining familiar work scenarios, providing a clear interface, maintaining a consistent design, and preventing failures when performing basic actions. Architectural criteria include reducing reliance on legacy components, minimizing code duplication, and simplifying system maintenance.

The model can be effective if the migration process is phased, allowing the application to continue working without interruptions and gradually reducing technical dependence on the old architecture.

The main risk associated with this approach is a potential disruption to the user experience if there is a mismatch between the old and new interfaces, logic, or behaviors of elements. To mitigate this risk, it is important to establish uniform design guidelines, use a common design system, and thoroughly test user scenarios prior to implementation.

Another risk is data incompatibility, session status, and access rights. This can be minimized by using a compatibility layer, standardized data exchange formats and critical scenario testing before migrating.

Additionally, it is possible to complicate the architecture and decrease performance during the migration phase. To avoid these issues, a migration plan, monitoring of interim solutions, regular removal of obsolete components, and continuous interface speed testing are necessary. If these requirements are met, an extended model allows for a safer and more manageable upgrade.

Conclusions

The M. Fowler model serves as an important basis for the phased modernization of software systems. However, when it comes to distributed application interface systems, it requires some expansion. The interface layer is responsible not only for displaying information but also for executing user scripts, interacting with server services, maintaining session status, and ensuring the integrity of the user experience. The extended model allows interface migration to be considered a managed process. It includes analyzing the existing system, defining migration zones, creating new interface modules, configuring routing, ensuring compatibility, and quality control. The use of this model helps reduce technical risks, maintain application stability, and make the transition from outdated interface solutions to a modern architecture more secure.

Glibina M.D. Comparative analysis of monolithic and microservice architecture of software development and design // Modern innovations in science and technology: collection of scientific papers of the 10th All-Russian scientific and technical conference with international participation. – 2020. – pp. 74-78.

Iordanashvili O.V., Pridvorov V.V., Kolomiytseva S.V. Approaches to improving the usability of user interfaces // Far East Math – 2022: Proceedings of the national scientific conference. – 2022. – pp. 106-111.

Kamolov A.B., Tuleubaeva A.A., Rychkov V.A., Davydenko V. Analysis of methods for deploying applications with microservice architecture // Proceedings of the III International Scientific and Practical Forum on Economic Security "VIII VSKEB": Collection of materials of the International Scientific and Practical Forum. – 2022. – pp. 31-38.

Kanaeva I.A., Magomedov M.A. Modern application development architectures // Information technologies in economics and management: collection of materials of the V All-Russian scientific and practical conference. – 2022. – pp. 120-123.

Karakhanova A.A. Analysis of microservice architecture, monolithic applications, SOA architecture // Synergy of Sciences. – 2020. – No. 46. – pp. 255-262.

Klyukovkin G.K. Design-for-Failure as a principle of designing corporate backend systems // the role of science and high technologies in ensuring the socio-economic development of the state: collection of scientific papers based on the materials of the International scientific and practical conference of September 13, 2021. Belgorod: Belgorod: The Agency for Advanced Scientific Research (APNI), LLC). – 2021. – URL: https://apni.ru/article/2914-design-for-failure-kak-princzip-proektirovaniya-korporativnyh-backend-sistem.

Klyukovkin G.K., Mikhailov B.A. Designing Fault-Tolerant Systems Taking into Account Extreme Load Peak s // Bulletin of Science and Creativity. – 2021. – No. 3 (63). – pp. 44-51.

Lavrentyeva I.S., Torkhov A.E. Designing an Architecture for the Server Side of the Academic Schedule Processing System // Innovative Development of Engineering and Technology in Industry (INTEX-2021): Collection of Materials of the All-Russian Scientific Conference of Young Researchers with International Participation. – 2021. – pp. 208-211.

Jackson C. Micro Frontends [Electronic resource] // Martin Fowler. – 2019. – June 19. – URL: https://martinfowler.com/articles/micro-frontends.html.

Strangler fig pattern [Electronic resource] // AWS Prescriptive Guidance. – URL: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html.