System and method for automatically implementing migration and portability of legacy application software

Abstract

The invention relates to a system for enabling migration and portability of legacy application software on the basis of application situations, in particular medical application situations, comprising: an input unit which is designed to read in data relating to a configuration of the legacy application software and a plurality of legacy service applications; a policy determination unit, which is configured to automatically determine a runtime architecture associated with the selected application situation on the basis of the read-in data; a transportability unit configured to load a transportability requirement based on the determined runtime architecture, the transportability requirement comprising a new service application linked to the legacy service application; a configuration unit configured to provide a new configuration of the legacy application software on the basis of the loaded transportability requirements; and an output unit which is designed to execute the application situation using the new configuration of the legacy application software.

Description

Technical Field

[0001] The invention relates to a system for automatically implementing application-specific migration and portability of legacy application software. The invention also relates to a computer-implemented method, a computer program product and a non-volatile computer-readable data storage medium for automatically implementing application-specific migration and portability of legacy application software. Background Art

[0002] Regardless of the grammatical part of speech of a particular term, people with either male or female gender identity are included.

[0003] Legacy applications, old applications or simply legacy software (also called legacy applications (legacy Apps)) are software products that were placed on the market under old regulations and with older existing technologies and are still available even though the old regulations are no longer valid.

[0004] Using the software in an environment with new rules illustrates challenges summarized in general terms of migration and portability. Migration and portability solutions should preferably be performed automatically. The lack of automatic migration and portability solutions often results in the need for manual adjustments, which can often be very time consuming.

[0005] In the context of medical applications, the portability of legacy applications and their migration into a secure environment is particularly complex, especially since medical applications and products often have a lifetime of several decades. Therefore, in companies there is often a compromise between maintaining installed legacy systems on the one hand and promoting innovation and modernization on the other. Added to this is the experience that innovation, after its lengthy development, carries with it the risk that it may become obsolete within a short period of time.

[0006] This involves all layers of the application software, from backend service applications to frontend service applications. Backend service applications are usually more stable, since they reflect business logic that does not change often. Frontend service applications are usually more critical, especially the user interface of the application, which is the main motivation for modernizing legacy applications. For efficiency reasons, frontend service applications are usually developed with the help of technical solutions that have a limited lifespan, which also makes rapid migration difficult.

[0007] Effective portability of applications means that the applications should not be reprogrammed in the new environment. However, this requires that the technical differences from the old environment to the new environment should be addressed. Aspects such as security standards or runtime environments are particularly challenging here. Legacy applications often have a monolithic architecture, so that the mentioned aspects cannot be addressed with modern technologies.

[0008] While in the earlier days of legacy applications service applications tended to be static, the current environment requires re-architecting and re-designing of control flows for the same application scenarios, which results in higher portability and migration costs.

[0009] One strategy for migration and portability is to use monolithic software. Recently, flexible software architectures based on modular architectures have been introduced, such as microservices and microfrontends. However, these software architectures usually need to solve portability before they can be used. Therefore, these software architectures also do not provide for application-specific migration of applications, which significantly limits their flexibility. The complexity of new application scenarios or possible software updates usually cannot be automatically performed, so that portability must always be performed manually again. Summary of the invention

[0010] Against this background, it is an object of the present invention to enable a more flexible and, in particular, application-dependent migration and portability of legacy application software.

[0011] According to the invention, the object is achieved by a system having the features of the present application and / or by a computer-implemented method having the features of the present application and / or by a computer program product and / or by a non-volatile computer-readable data storage medium.

[0012] Preferred embodiments of the invention having advantageous features are the subject of the following description.

[0013] According to a first aspect, the present invention provides a system for implementing the migration and portability of legacy application software based on application scenarios, especially medical application scenarios, the system comprising: an input unit, which is configured to read in data about the configuration of the legacy application software and multiple legacy service applications; a policy determination unit, which is configured to automatically determine a runtime architecture associated with a selected application scenario based on the read-in data; a portability unit, which is configured to load portability requirements based on the determined runtime architecture, wherein the portability requirements include new service applications linked to the legacy service applications; a configuration unit, which is configured to provide a new configuration of the legacy application software based on the loaded portability requirements; and an output unit, which is designed to execute the application scenario with the help of the new configuration of the legacy application software.

[0014] Legacy application software, also called old application software or legacy application program, is understood to be software set up to provide multiple applications / application programs. Typically, legacy application software includes different legacy service applications that can be executed in a runtime environment (including, for example, at least one hardware and an operating system).

[0015] An application scenario is any application that a user of the legacy application software can execute using the legacy application software. This implementation is usually performed under the condition of operating a user interface. Each application scenario uses multiple service applications / service application programs.

[0016] The legacy service application is an application that is a component of the legacy application software and includes an application programmed during the development of the legacy application software together with corresponding software updates.

[0017] New or modern service applications are applications that can be implemented using current operating systems and current requirements, such as security protocols. New service applications are not part of the legacy application software, but are part of the migration and portability solution.

[0018] The runtime architecture is a design of different components that enable migration and portability solutions for application scenarios. The runtime architecture includes a number of portability requirements. The portability requirements relate in particular to the determination of the runtime environment, the determination of the service applications together with the required service infrastructure and / or the required functionality of the user interface. The runtime architecture also determines the links between legacy service applications and new service applications, which are necessary for portability and migration of application scenarios.

[0019] The new configuration of the legacy application software includes all the information needed to implement a migration and portability solution as software. The configuration rewrite contains said information of the runtime architecture so that it can be executed as software.

[0020] Different devices (units, modules and interfaces) generally include devices and computer programs that can receive, process and evaluate data. The devices are connected to each other wired and / or wirelessly so that signals can be exchanged. Therefore, the device includes at least one central processing unit (CPU) and / or at least one graphics processing unit (GPU) and / or at least one field programmable gate array (FPGA) and / or at least one application-specific integrated circuit (ASIC) and / or any combination of the aforementioned devices. Each device may also include a working memory operably connected to at least one CPU and / or a non-volatile memory operably connected to at least one CPU and / or working memory. Each device may be partially and / or completely implemented in a local device and / or partially and / or completely implemented in a remote system, such as a cloud computing platform.

[0021] Different devices can be implemented in hardware and / or software and / or partly in hardware and partly in software, wired and / or wireless and any meaningful combination thereof. It can also include interfaces with intranets, the Internet, local area networks, cloud computing services, remote servers, etc.

[0022] In a cloud computing-based system, a large number of devices are connected to the cloud computing system via the Internet. The devices may be in a remote device connected to the cloud computing system. The devices may include, or be composed of, electrical or electronic devices, sensors, actuators, robots and / or machines in one or more industrial facilities. The devices may be household appliances, office equipment in residential / commercial facilities, production machines, medical equipment, measuring equipment, etc.

[0023] Cloud computing systems can enable remote configuration, monitoring, control, and maintenance of connected devices (also commonly referred to as "assets"). In addition, cloud computing systems can simplify storing large amounts of data regularly detected by devices, analyzing large amounts of data, and providing knowledge (e.g., performance indicators, abnormal values, etc.) and warnings to operators, external service engineers, or owners of devices via a graphical user interface (e.g., a web application). The knowledge and warnings can enable control and maintenance of the equipment, which results in efficient and fail-safe operation of the equipment. Cloud computing systems can also enable changing parameters associated with the equipment. Finally, cloud computing systems can also output control commands, such as those obtained based on the knowledge and warnings, via a graphical user interface.

[0024] A cloud computing system may include multiple servers or processors that are geographically distributed and connected to each other via a network (also referred to as "cloud infrastructure"). A specific platform (hereinafter referred to as "cloud computing platform") is installed on the server / processor, which provides the above functions as a service (hereinafter referred to as "cloud service"). The cloud computing platform may include multiple software programs executed on one or more servers or processors of the cloud computing system to enable the provision of one or more required services to the device and its users.

[0025] One or more application programming interfaces (APIs) are used in a cloud computing system to provide different cloud services to users.

[0026] The policy determination unit, the portability unit and the configuration unit may in particular implement software, program routines or algorithms with different data processing capabilities.

[0027] The input unit and the output interface can include in particular an interface, for example an application programming interface (API), by means of which the input unit can in particular read in text data and imaging data and the output interface can output processed imaging data with the partitioning.

[0028] The policy determination unit and / or the portability unit may include an artificial intelligence module.

[0029] Artificial intelligence is understood to be a computer-aided device or apparatus for implementing various data analysis methods, which are also often referred to as artificial intelligence, machine learning, deep learning, computer learning, etc. The core of most devices with artificial intelligence is a trained or trainable artificial neural network (ANN).

[0030] In this document and hereinafter, an artificial neural network (also often referred to as an encoder) is understood to be a computing system based on a collection of connected units or nodes divided into one or more layers or hierarchies capable of transmitting signals to each other, and preferably at least partially includes a converter network architecture.

[0031] According to some examples, the portability means is configured to identify legacy service applications (required for the application scenario) based on the runtime architecture and link the identified legacy service applications with the new service applications in order to provide portability requirements.

[0032] According to some examples, the portability means is configured to link the new service application and the legacy service application to each other based on semantic links.

[0033] With the help of semantic linking, applications can be linked according to the situation based on the (abstract) characteristics of the application. This means that the linking is not based on a predefined link table. This means that links between legacy service applications and new service applications can also be created for unknown runtime architectures / application situations and executable configurations can be provided.

[0034] According to some examples, in order to establish semantic links, the portability unit is configured to classify legacy service applications based on semantics to provide legacy classifications, classify new service applications based on semantics to provide new classifications, and link the legacy service applications and the new service applications to each other based on the legacy classifications and the new classifications.

[0035] In other words, legacy service applications and new service applications can be classified according to semantics. For example, semantics can include functions, meanings, behaviors, input / output variables, and / or other characteristics and / or any combination of the aforementioned characteristics. In addition, semantics can also include less clear characteristics. In particular, semantics can be semantics learned by machine learning.

[0036] Providing a classification (legacy or new) can in particular comprise generating a feature vector for the corresponding service application based on semantics. The linking between the legacy service application and the new service application can in particular be based on a comparison of the corresponding feature vectors. In particular, legacy service applications and new service applications having similar or identical feature vectors can be linked to each other. For example, the similarity between the feature vectors can be determined by forming cosines. The feature vector can in particular comprise one or more characteristics of the service application.

[0037] By means of such a semantic analysis, links can also be created in such application cases in which there is no 1:1 correspondence between legacy service applications and new service applications.

[0038] According to some examples, the portability apparatus is configured to determine semantics based on a runtime architecture.

[0039] For example, specific features / characteristics of the semantics can be defined (activated or deactivated) depending on the runtime architecture, which are important for the underlying application case. Thus, depending on the hardware or operating system or the range of functions sought, different characteristics are important when linking service applications. As a result, the semantic linking can be dynamically adapted to the respective application case.

[0040] According to a second aspect, the present invention also implements a computer-implemented method for achieving migration and portability of legacy application software, the method having the following steps: selecting an application scenario; reading in data about the configuration of the legacy application software and multiple legacy service applications; automatically determining a runtime architecture associated with the selected application scenario based on the read-in data; loading portability requirements based on the determined runtime architecture, wherein the portability requirements include a new service application linked to the legacy service application; providing a new configuration of the legacy application software based on the loaded portability requirements; and executing the selected application scenario with the help of the new configuration of the legacy application software.

[0041] The computer-implemented method according to the second aspect of the invention can be advantageously performed, for example, by means of a system according to the first aspect of the invention. Therefore, the features and advantages described herein in conjunction with the system and its working method also apply to the method in the same manner and vice versa.

[0042] According to a third aspect, the present invention also realizes a computer program product, which comprises an executable program code, which is designed to perform the method according to the second aspect of the present invention when the program code is executed.

[0043] According to a fourth aspect, the present invention provides a non-volatile computer-readable data storage medium, the data storage medium comprising an executable program code, the program code being configured to, when the program code is executed, perform the method according to the second aspect of the present invention.

[0044] The non-volatile computer-readable data storage medium may include or consist of any type of hardware memory, in particular semiconductor memory such as solid-state memory. The data storage medium may also include or consist of a CD, DVD, Blu-ray disc, USB memory stick, hard disk, etc.

[0045] The idea on which the invention is based is to provide a system for portability and migration of legacy application software, which determines individual migration and portability solutions based on given application scenarios. The solution is based on linking modern software applications with legacy applications. Each application scenario has a different, automatically determined linking strategy. Two application scenarios can be executed one after the other by replacing the linking strategy of the first application scenario with the linking strategy of the second application scenario. By implementing and de-implementing the linking strategy, the legacy application software can be transferred to different application scenarios.

[0046] The above-described system advantageously enables a computer-implemented method for implementing application-based migration and portability of legacy application software. In this case, an application case is first selected. Data about the configuration of the legacy application software and available legacy service applications are read in. A matching runtime architecture for the selected application case is then automatically determined. Based on this, the associated portability requirements of, for example, modern service applications are loaded and linked to the legacy service application. The linking strategy provides a new configuration of the legacy application software that matches the selected application case. With the help of the new configuration, the corresponding selected or to-be-selected application case can be executed.

[0047] One advantage of the invention is that by linking different modern software applications with legacy applications, the portability and migration of legacy applications can be individually adapted to different application cases. The linking can be determined based on the application case and run automatically. Thus, portability and migration are performed by linking modern software applications in relation to the application case. Thus, the legacy application remains unchanged. This provides a flexible and adaptive migration.

[0048] Another advantage of the present invention is that the new software components and the legacy software components are linked so that the legacy application software can call and execute different legacy service applications as usual.

[0049] Another advantage of the present invention is that legacy applications and modern applications can be updated independently without compromising portability and migration.

[0050] Advantageous embodiments and developments emerge from the description with reference to the figures of the attached drawing.

[0051] According to another embodiment of the present invention, the legacy software application is a medical legacy software application. In the medical field, portability and migration solutions are particularly important, because the lifespan or update frequency of some medical software applications may be completely different. Service applications of medical applications, for example, must be adapted to frequently changing safety measures. This causes the emergence of legacy problems associated with medical legacy software applications, which should be eliminated as quickly as possible.

[0052] According to another embodiment of the present invention, the new configuration of the legacy application software includes changes in partial areas of the legacy application software, in which the legacy service application is only partially used and / or a part of the user interface is replaced. The partial areas of the legacy application software include, for example, the runtime environment, the legacy service application and the service infrastructure (such as licensing, data access, data transmission, security requirements and other legal requirements), the user interface and other functional and non-functional requirements. According to the present invention, the number of active legacy service applications and the corresponding links with the new service application are designed very flexibly and depend on the application situation. For one application situation, the corresponding determined runtime architecture may require the omission of some legacy service applications. For another application situation, it may be necessary to replace a part of the user interface.

[0053] According to another embodiment of the present invention, the portability requirement also includes the configuration of the runtime environment and / or security features and / or the user interface. The linking strategy according to the present invention enables the replacement or supplementation of different partial areas of the legacy application software. Because all partial areas of the legacy application software can be changed and adjusted, the portability requirement can also be designed flexibly.

[0054] According to another embodiment of the present invention, the portability unit is also set up to provide access to new service applications that are not linked to legacy service applications through the configuration of the user interface. According to the present invention, the legacy service application can be executed through the legacy user interface even if it is linked to the new service application. On the contrary, the new service application that is not linked to the legacy application can be executed by changing the user interface. Expanding the service application of the legacy application software in order to provide a new service application can also be understood as migration and portability. The application situation may require a current secure login, for example. The new service application cannot be called with the help of the legacy user interface. However, the new configuration of the user interface (by replacing or supplementing some parts of the user interface) can provide a secure login as a new service application.

[0055] According to another embodiment of the present invention, the system further includes a database unit, which is designed to provide at least one application scenario list, a list of new service applications, and a list of runtime architectures. Therefore, the application scenario can be selected by a user or an operator. The determined runtime architecture can also be selected from the list. The runtime architecture can be implemented with the help of a list of portability requirements. The system of the present invention can call the portability requirements from the list of new service applications. Therefore, the database unit can be understood as a software library to a certain extent. The runtime architecture and portability requirements determined by the system can be stored in the database unit in a callable manner. The stored runtime architecture includes metadata that associates the runtime architecture with the new service applications and portability requirements (for example, different required links).

[0056] According to another embodiment of the present invention, portability requirements include changes in the front end of the legacy application software and changes in the back end of the legacy application software, and the changes are independent of each other. It is common that the front end of the application software must be updated more frequently than its back end. The user interface and security measures of the application usually change faster than the application situation. Therefore, there are different requirements in the legacy application software that require separate solutions. According to the present invention, the new application and the legacy application are decoupled. They can be connected according to different link strategies. The links can be revoked independently of each other. Correspondingly, it is feasible to change the link, for example because it is necessary to only involve the update of the link. The flexibility of the system according to the present invention enables the requirements of the front end and the back end to be handled independently of each other.

[0057] According to another embodiment of the present invention, the portability unit is also configured to work with a conventional runtime architecture, in particular a runtime architecture comprising microservices or microfrontends. The flexibility and adaptability of the present invention cause the portability unit to work in combination with a conventional modular and flexible software architecture.

[0058] According to a further embodiment of the invention, it is proposed that the system further comprises a verification unit, which is designed to verify the implemented migration and portability, in particular in order to cause a repair or filling of the database unit. The migration and portability solution provided by the determined runtime architecture may not be implemented in some cases, for example, because no suitable new service application is found in the database unit or because compatibility problems occur. The verification unit ensures that the problems are detected and identified.

[0059] According to another embodiment of the present invention, the portability unit is also set up to perform the orchestration of the loaded portability requirements and redirect the execution calls from the legacy application software to the portability requirements. An important feature of the present invention is that the legacy application software is ported without changing the existing execution calls. The redirection of the execution calls can be a component of the linking strategy. The linking strategy can also include the orchestration of new service applications and legacy service applications.

[0060] According to another embodiment of the present invention, the runtime architecture is implemented in a desktop or in a container, especially in an edge or cloud environment. The migration solution of the present invention ensures that the application scenarios of the legacy application software can be executed in different runtime environments.

[0061] According to another embodiment of the present invention, the system further comprises a storage unit, which is configured to store new configurations of the legacy application software. Therefore, all information is provided for reuse and can be changed and called in a version-controlled manner.

[0062] Although some functions are described herein and hereinafter as being performed by units or devices, this does not necessarily mean that the units or devices are provided as independent, matching or separate units or devices. In the case where one or more units or devices or a part thereof are provided as software, the units or devices may be implemented by program code segments or program code sections, which may be separate from each other, but may also be interwoven or integrated with each other. It is also conceivable to have program code with program code segments or program code sections distributed on multiple units or devices, as is feasible, for example, in cloud computing.

[0063] Likewise, where one or more units and / or devices are provided as hardware, the functionality of one or more units or devices may be provided by the same hardware component, or the functionality of multiple units and / or devices may be distributed over multiple hardware components that do not necessarily correspond to the units or devices. Thus, each application, each system, each method, etc. may have all the features and functionality attributed to a particular unit or device, including or implementing said unit or device. It is particularly feasible that all units are implemented by program code executed by, for example, a server or a cloud computing platform.

[0064] As long as it makes sense, the above-mentioned designs and improvements can be combined with each other arbitrarily. Other feasible designs, improvements and implementations of the present invention also include combinations of features of the present invention described above or below with respect to the embodiments that are not explicitly mentioned. Here, those skilled in the art will also add individual aspects as improvements or supplements to the corresponding basic forms of the present invention.

[0065] The further scope of applicability of the present method and apparatus becomes apparent from the following drawings and detailed description. However, it is self-evident that the detailed description and specific examples, although illustrating preferred embodiments of the present invention, are primarily for illustration, and different changes and modifications within the basic idea and scope of the present invention will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] The invention is described below with reference to advantageous embodiments of the invention with reference to the accompanying drawings, which serve to further illustrate embodiments that contain the concept of the claimed invention and to explain various principles and advantages of the embodiments.

[0067] The accompanying drawings show:

[0068] Figure 1 A system for implementing migration and portability of legacy application software based on application situations according to one embodiment of the present invention is shown;

[0069] Figure 2 A schematic block diagram showing the flow of a computer-implemented method for implementing migration and portability of legacy application software based on application scenarios according to one embodiment of the present invention;

[0070] Figure 3 A schematic block diagram illustrating the migration and portability of legacy application software according to one embodiment of the present invention;

[0071] Figure 4 A schematic block diagram showing migration and portability of legacy application software for a first application scenario according to one embodiment of the present invention;

[0072] Figure 5 A schematic block diagram showing migration and portability of legacy application software for a second application scenario according to one embodiment of the present invention;

[0073] Figure 6 shows a schematic block diagram illustrating a computer program product according to an embodiment of the third aspect of the present invention; and

[0074] Figure 7 A schematic block diagram showing a non-volatile computer-readable data storage medium according to an embodiment of the fourth aspect of the present invention is shown.

[0075] In the figures of the drawings, identical, similar or functionally similar elements are respectively denoted by the same reference numerals, unless stated otherwise.

[0076] The elements shown in the figures of the accompanying drawings are not necessarily shown to scale. The accompanying drawings are mainly used to illustrate the basis and principle of the present invention and make it clear. In a similar manner, in some cases, known structures and devices are shown in the form of block diagrams in order to illustrate the feasible concept of the present invention.

[0077] The numbering of the steps in the method should simplify its description. The numbering does not necessarily imply a specific order of the steps, unless otherwise explicitly stated. In particular, multiple steps can also be carried out simultaneously and / or multiple times and / or there can be intermediate steps that are not shown.

[0078] The detailed description of the figures attached to the drawings includes specific details in order to provide a thorough understanding of the present invention. However, it is apparent to one skilled in the art that the present invention can be practiced without these specific details when necessary.

[0079] Specific implementation instructions

[0080] Figure 1 A system 100 for enabling migration and portability of legacy applications based on application scenarios according to one embodiment of the present invention is shown. The legacy applications may be medical legacy applications, for example, to read or report information about a patient, such as treatments, planned and proposed interventions, results of tests, etc.

[0081] The system 100 includes an input unit 10 , a policy determination unit 20 , a portability unit 30 , a configuration unit 40 , an output unit 50 , a database unit 60 , a verification unit 70 , and a storage unit 80 .

[0082] The input unit 10 is designed to read in data D0 about the current configuration of the legacy application software. The data D0 includes, in particular, available legacy service applications, the runtime environment of the legacy application software and information about the service infrastructure.

[0083] The policy determination unit 20 is configured to determine a runtime architecture associated with the selected application scenario. The determination acquires the read data D0 and provides a new runtime architecture based on the read data. The runtime architecture can be implemented in a desktop or in a container, in particular in an edge or cloud environment. In some embodiments of the present invention, an algorithm can be used for determination. In other embodiments, the policy determination unit 20 may include an artificial intelligence module 210 that implements an artificial intelligence model. The artificial intelligence model 210 may be a component of the algorithm and / or may be used to optimize the algorithm.

[0084] The portability unit 30 is set up to load the portability requirements corresponding to the determined runtime architecture. The portability requirements involve all software components of the application software and their required links. The portability requirements include changes to the front end of the legacy application software and / or changes to the back end of the legacy application software, and the changes can preferably be performed independently of each other.

[0085] The portability requirement is determined depending on the application case and may include the runtime environment, the user interface and the service applications associated with the application case. It is therefore feasible that the portability requirements include new service applications and legacy service applications, preferably together with information on how the new service applications and the legacy service applications must be connected. In addition, the portability unit 30 can be set up to work with traditional runtime architectures, which in particular include microservices or microfrontends. The portability unit 30 can also be set up to perform the orchestration of the loaded portability requirements and redirect execution calls from the legacy application software to the portability requirements.

[0086] The configuration unit 40 is configured to provide a new configuration of the legacy application software based on the loaded portability requirements. In some embodiments of the present invention, the configuration may be compiled into an executable code.

[0087] The output unit 50 is used to execute the application scenario with the new configuration of the legacy application software. The output unit 50 may include at least one CPU, a data memory and an interface, such as an application programming interface (API). The API may be wirelessly coupled and / or wiredly connected to the legacy application software.

[0088] In some embodiments, as in Figure 1 As shown, the system 100 also includes a database unit 60. The database unit 60 is designed to provide at least one application situation list, a list of new service applications and / or a list of runtime architectures. In some embodiments, the database unit 60 includes an application situation module 610, and the application situation module 610 is designed to maintain or archive a list of application situations. In other embodiments, the database unit 60 includes a runtime architecture module 620, and the runtime architecture module 620 is designed to maintain or archive a list of new runtime architectures. In other embodiments, the database unit 60 includes a service application module 630, and the service application module 630 is designed to maintain or archive a list of new service applications. Figure 1 In the embodiment shown in FIG. 8 , the database unit 60 includes an application situation module 610 , a runtime architecture module 620 and a service application module 630 .

[0089] The application scenario module 610 may be connected to a user interface. Thus, available application scenarios may be selected from a list of application scenarios of a user or user.

[0090] The runtime architecture module 620 can save the runtime architecture (also determined by the policy determination unit 20) in a list. The runtime architecture can store information about the corresponding portability requirements. The stored runtime architecture includes metadata that associates the runtime architecture with the new service application and the portability requirements, such as different required links.

[0091] In some embodiments of the invention, the portability unit 30 can select a runtime architecture that matches the application case from the runtime architecture module 620 of the database unit 60. This is particularly advantageous if the migration and portability solution for the application case has been determined in advance by the policy determination unit 20. This can be achieved according to different variants. According to a variant, the determination of the policy determination unit 20 can be driven by the input unit 10 when the runtime architecture for the selected application case has not been determined so far.

[0092] New service applications associated with the portability requirements of the runtime architecture may be invoked, at least in part, by the service application module 630 .

[0093] Figure 1 The system 100 also includes a verification unit 70, which is set up to verify the achieved migration and portability, especially to cause repair or refilling of the database unit 60. The migration and portability solutions provided by the determined runtime architecture may not be implemented in some cases. In some cases, it is possible that no matching new service application is found. Therefore, the portability requirements cannot be met. In other cases, portability problems may occur. The verification unit 70 ensures that different problems are detected and identified. The information about the problems that occur can be forwarded to the user using a user interface. The verification unit 70 may include a CPU, a data storage device and an interface, such as an application programming interface (API). The API can be wirelessly coupled to the user interface or connected by wire.

[0094] exist Figure 1 The storage unit 80 shown in FIG. 1 is set up for storing new configurations of legacy application software. Configurations associated with application situations can be called and used from the storage unit 80 as needed. The storage unit 80 can be a data storage medium, such as a DVD, a hard disk, a USB memory, etc. Alternatively, the storage unit 80 can also be a component of a computer, a server and / or be in a cloud platform. According to some embodiments, the storage unit 80 can be included by the database unit 60.

[0095] Figure 2A schematic block diagram showing the flow of a computer-implemented method for implementing migration and portability of legacy application software based on application scenarios according to one embodiment of the present invention. The method can advantageously be implemented by means of a method corresponding to Figure 1 The system 100 is executed.

[0096] In step S1, an application scenario is selected. This can be performed by a user, for example, using an appropriate user interface. In some embodiments of the invention, the user interface can provide, for example, a list of application scenarios that can be called up from the database unit 60. The user interface can be coupled to the database unit 60 wirelessly or connected by wire.

[0097] In step S2, data D0 associated with the current configuration of the legacy application software, under which a plurality of legacy service applications exist, is read in.

[0098] In a subsequent further step S3 , a runtime architecture adapted to the application is automatically determined. The automatic determination can be performed using a suitable algorithm, for example, an algorithm containing a trained or trainable artificial intelligence model.

[0099] In step S4, the portability requirements of the implementation that can realize the determined runtime architecture are loaded. The portability requirements involve all software components of the application software and involve the links required to each other. Therefore, the portability requirements may include new service applications and legacy service applications, together with information on how the new service applications and legacy service applications must be connected.

[0100] In the next step S5 , a new configuration of the legacy application software is provided. In some embodiments, the configuration may be compiled into an executable code and stored in the storage unit 80 .

[0101] Finally, in step S6 , the selected application scenario is executed with the aid of the new configuration of the legacy application software. The configuration can be called up from the storage unit 80 .

[0102] Figure 3 A schematic block diagram is shown for illustrating the migration and portability of legacy application software according to one embodiment of the present invention. The block diagram shows legacy application software with legacy service applications Srv1, Srv2 and Srv3, a legacy user interface UI and a service infrastructure InfrSrv. The application scenario is executed in a runtime environment RunT with the aid of a container CntH by means of the legacy application software. The runtime environment RunT includes an operating system and hardware. Different application scenarios that can be executed with the aid of the legacy application software can be called through the legacy user interface UI. Each application scenario uses a different combination of service applications Srv1, Srv2 and Srv3.

[0103] In addition, Figure 3The block diagram of FIG. 1 shows the legacy application software as it is migrated according to the present invention. Figure 3 A feasible runtime architecture that can be provided in association with an application scenario is shown. In addition to the legacy service applications Srv1, Srv2, and Srv3, Figure 3 New service applications SrvN1, SrvN2 and SrvN3 are shown together with a user interface UIA and a service infrastructure InfrSrVA. Different application scenarios can be executed with the aid of migrated legacy applications with the aid of containers CntHA in the runtime environment RunTA.

[0104] exist Figure 3 The runtime architecture shown on the right side of is determined by the policy determination unit 20. The portability unit 30 can call the required new service applications SrvN1, SrvN2 and SrvN3 from the service application module 630 of the database unit 60, and link the new service applications with the legacy service applications Srv1, Srv2 and Srv3 and the user interface UIA. The link is designed so that the legacy service applications in the legacy service applications Srv1, Srv2 and Srv3 that are linked to the new service applications in the service applications SrvN1, SrvN2 and SrvN3 should be executed just as before portability and migration. This is done from the legacy user interface UI through the relevant components of the user interface UIA. On the contrary, the new service applications in the service applications SrvN1, SrvN2 and SrvN3 that are not linked to the legacy applications Srv1, Srv2 and Srv3 can be executed by replacing the components of the user interface UIA.

[0105] The defined runtime architecture also ensures that the application scenarios can be executed in the new runtime environment RunTA by means of the migrated legacy application software by means of the container CntHA.

[0106] Figure 4 Another schematic block diagram is shown for explaining the migration and portability of legacy application software for a first application scenario according to one embodiment of the present invention. The determined runtime architecture providing a migration and portability solution for the application scenario defines legacy service applications Srv1 and Srv2, a legacy user interface UI, new service applications SrvN2 and SrvN3, a new service infrastructure InfrSrvA1, a new container CntAH1 and a legacy runtime environment RunT as portability requirements. The legacy service applications Srv1 and Srv2 are linked to the legacy user interface UI.

[0107] according to Figure 4In the example shown in FIG. 1 , a new service infrastructure InfrSrvA1 and a new container CntHA1 are needed to implement new service applications SrvN2 and SrvN3. The new service infrastructure InfrSrvA1 may include current licenses or information about data transmission. In medical software applications, data transmission is mediated, for example, by so-called Fast Healthcare Interoperability Resources (FHIR).

[0108] The new service applications SrvN2 and SrvN3 are linked with the legacy service application Srv2. The portability unit 30 ensures that the links are designed so that the legacy service application Srv2 can be executed using the user interface UI just as before portability and migration.

[0109] Figure 5 A schematic block diagram of the migration and portability of legacy application software for a second application scenario according to one embodiment of the present invention is shown. In the example, the corresponding determined runtime architecture includes a new service application SrvN1, no legacy service application, a changed user interface UIA2, a new service infrastructure InfrSrvA2, a new container CntHA2 and a new runtime environment RunTA2.

[0110] The new service application SrvN1 can be executed through the user interface UIA. The application scenario shown can be, for example, a secure login. The new service application SrvN1 may not be called by the legacy user interface. The configuration of the user interface UIA2, which can be performed, for example, by replacing or supplementing some parts of the user interface UI, can provide the required secure login. The secure login is based on the current security protocol implemented, for example, in the new service infrastructure InfrSrvA2. The secure login typically cannot be performed with the help of Windows 8 (as an example of a legacy operating system), but Windows 11 (as an example of a more recent operating system) is required for this. A new runtime environment RunTA2 and a new container CntHA2 are required so that a secure login can be performed with the help of the ported legacy application.

[0111] exist Figure 4 and Figure 5 The runtime architecture identified in can work together with traditional runtime architectures, especially runtime architectures that include microservices or microfrontends. Figure 5 The user interface UIA2 shown in FIG. 1 can be designed with the help of microservices.

[0112] Figure 6A schematic block diagram of a computer program product 300 is shown to illustrate an embodiment of the third aspect of the present invention. The computer program product 300 comprises an executable program code 350, wherein the program code 350 is configured to execute, when the program code is executed, the program code executes the method according to any embodiment of the second aspect of the present invention, in particular as described above. Figures 1 to 5 Described in .

[0113] Figure 7 A schematic block diagram of a non-volatile computer-readable data storage medium 400 is shown to illustrate an embodiment of the fourth aspect of the present invention. The data storage medium 400 includes an executable program code 450, and the program code 450 is configured such that when the program code is executed, the program code performs the method of any embodiment of the second aspect of the present invention, in particular as described above. Figures 1 to 5 Described in .

[0114] The non-volatile computer-readable data storage medium may include any type of computer memory, and in particular may be designed as or consist of a semiconductor memory or a solid-state memory. The data storage medium may also include or consist of a CD, a DVD, a Blu-ray disc, a hard disk, a USB memory stick, etc. Cloud-based storage is also conceivable.

Claims

1. A system (100) for implementing migration and portability of legacy application software based on application scenarios, in particular medical application scenarios, comprising: An input unit (10) configured to read in data (D0) about the configuration of the legacy application software and a plurality of legacy service applications; a strategy determination unit (20) configured to automatically determine a runtime architecture associated with a selected application scenario based on the read-in data; a portability unit (30) configured to load portability requirements based on the determined runtime architecture, wherein the portability requirements include a new service application linked with the legacy service application; a configuration unit (40) configured to provide a new configuration of the legacy application software based on the loaded portability requirements; as well as An output unit (50) is designed to execute the application scenario by means of a new configuration of the legacy application software.

2. The system according to claim 1, Wherein the legacy application software is a medical legacy application software.

3. A system according to any one of the preceding claims, The portability unit is configured to link the new service application and the legacy service application to each other based on semantic links.

4. The system according to claim 3, In order to establish the semantic link, the portability unit is configured to: - classifying said legacy service applications based on semantics so as to provide a legacy classification, - classifying new service applications based on said semantics in order to provide new categories, and - linking the legacy service application and the new service application to each other based on the legacy classification and the new classification.

5. The system according to claim 4, Wherein the portability unit is configured to determine the semantics based on the runtime architecture.

6. A system according to any one of the preceding claims, The new configuration of the legacy application software includes changes to some areas of the legacy application software.

7. A system according to any one of the preceding claims, The portability requirements may also include configuration of the runtime environment and / or security features and / or user interface.

8. The system according to claim 7, The portability unit (30) is further configured to provide access to a new service application that is not linked to the legacy service application through the configuration of the user interface.

9. The system according to any one of the preceding claims, further comprising a database unit (60), which is designed to provide at least a list of application scenarios, a list of new service applications and a list of runtime architectures.

10. A system according to any one of the preceding claims, The portability requirement includes changes to the front-end of the legacy application software and changes to the back-end of the legacy application software, and the changes are independent of each other.

11. A system according to any one of the preceding claims, The portability unit (30) is also designed to interact with conventional runtime architectures, in particular runtime architectures containing microservices or microfrontends.

12. The system according to any of the preceding claims, further comprising a verification unit (70) which is designed to verify the implemented migration and portability, in particular in order to cause a repair or filling of the database unit (60).

13. A system according to any one of the preceding claims, The portability unit (30) is further configured to execute the orchestration of the loaded portability requirements and redirect execution calls from the legacy application software to the portability requirements.

14. A system according to any one of the preceding claims, The runtime architecture is implemented in a desktop or in a container, in particular in an edge or cloud environment.

15. The system according to any of the preceding claims, further comprising a storage unit (80) configured to store a new configuration of the legacy application software.

16. A computer-implemented method for achieving migration and portability of legacy application software, preferably using the system according to any one of claims 1 to 12, the computer-implemented method having the following steps: Select (S1) application situation; reading (S2) data about the configuration of the legacy application software and a plurality of legacy service applications; Automatically determining ( S3 ) a runtime architecture associated with the selected application scenario based on the read-in data; loading (S4) portability requirements based on the determined runtime architecture, wherein the portability requirements include a new service application linked with the legacy service application; providing (S5) a new configuration of the legacy application software based on the loaded portability requirements; as well as The selected application scenario is executed ( S6 ) using the new configuration of the legacy application software.

17. A computer program product (300), comprising an executable program code (450), the program code (450) being designed to perform the computer-implemented method according to claim 16 when the program code is executed.

18. A non-volatile computer-readable data storage medium (400), the data storage medium (400) comprising an executable program code (450), the program code (450) being designed to perform the computer-implemented method according to claim 16 when the program code is executed.

Images