Integration of legacy systems into a modern enterprise SOA - Part 8 (last part)
8. Conclusion
The integration into a modern architecture can often be an opportune and flexible alternative to full replacement or redevelopment of an existing legacy system. The advantages of an integration using the SOA approach are:
- preservation of the business logic of the legacy system
- reduction of risk: No expensive and complex replacement or redevelopment necessary
- reduction of TCO
- Usage of the existing modern (SOA-) IT landscape (including infrastructure and hardware)
- guranteed future and flexibility because of standards, frameworks and reference architectures
- modern business processes because of service-oriented architectures and their advantages (loose coupling, reusability, flexibility, interoperability, standardization, less maintanance, ...)
The integration of legacy systems into a modern IT landscape kann be a complex project. Endurance is needed for the development to a flexible and agile company.
Montag, 23. April 2012
Montag, 16. April 2012
Integration of legacy systems into a modern enterprise SOA (part 7.3)
Integration of legacy systems into a modern enterprise SOA - Part 7.3
7. Approach
5. Transformations
The required data transformations or the necessary mapping must be implemented at the interface. For this the essential transformation steps have to be identified and implemented. If necessary the creation of mapping tables for data and business objects is inevitable. If a canonical data model exists, the transformations and the mapping are directly based on that. If, in one of the earlier phases you decided to implement a canonical data model, this is the time to implement and integrate it.
6. Adjust the calling business logic
Often, changes in the logic of the calling business processes are also necessary. Possibly, activites and processes have to be newly cut or stripped down, so that the call to the legacy system can be integrated.
7. Integrate the legacy interface into the SOA landscape
In a final step the legacy system will be integrated into the present SOA landscape. The needed web service calls and adaptors are integrated into the available business logic.
Part 8 will follow next week...
7. Approach
5. Transformations
The required data transformations or the necessary mapping must be implemented at the interface. For this the essential transformation steps have to be identified and implemented. If necessary the creation of mapping tables for data and business objects is inevitable. If a canonical data model exists, the transformations and the mapping are directly based on that. If, in one of the earlier phases you decided to implement a canonical data model, this is the time to implement and integrate it.
6. Adjust the calling business logic
Often, changes in the logic of the calling business processes are also necessary. Possibly, activites and processes have to be newly cut or stripped down, so that the call to the legacy system can be integrated.
7. Integrate the legacy interface into the SOA landscape
In a final step the legacy system will be integrated into the present SOA landscape. The needed web service calls and adaptors are integrated into the available business logic.
Part 8 will follow next week...
Dienstag, 10. April 2012
Integration of legacy systems into a modern enterprise SOA (part 7.2)
Integration of legacy systems into a modern enterprise SOA - Part 7.2
7. Approach (part 2)
3. Choise of adaptors and connectors
By means of the analysis of the legacy systems, the decision can be made, if it can easily later be augmented with modern interface technologies (java interfaces, web services). The choice of the right communication technology depends on that. Depending on the demands of performance and transaction security, oftentimes this decision is made towards Java Connector Architecture (JCA) and/or the WS framework. The use of a standard adapter, which is offered my different software companies, often represents the low-priced alternative. If the demands or the legacy systems do not allow the use of standard adapters, these can also be developed by yourself. The JCA framework is often used for this.
4. Customizing the legacy system
As said it is often necessary to implement changes in the legacy system, to be able to integrate it into a modern SOA. If the documentation was evaluated as "not sufficient" in the planning phase, an additional phase of documentation must be carried out. In a worst case scenario this could meand reverse engineering. The necessary changes can then be implemented.
Part 7.3 will follow next week...
7. Approach (part 2)
3. Choise of adaptors and connectors
By means of the analysis of the legacy systems, the decision can be made, if it can easily later be augmented with modern interface technologies (java interfaces, web services). The choice of the right communication technology depends on that. Depending on the demands of performance and transaction security, oftentimes this decision is made towards Java Connector Architecture (JCA) and/or the WS framework. The use of a standard adapter, which is offered my different software companies, often represents the low-priced alternative. If the demands or the legacy systems do not allow the use of standard adapters, these can also be developed by yourself. The JCA framework is often used for this.
4. Customizing the legacy system
As said it is often necessary to implement changes in the legacy system, to be able to integrate it into a modern SOA. If the documentation was evaluated as "not sufficient" in the planning phase, an additional phase of documentation must be carried out. In a worst case scenario this could meand reverse engineering. The necessary changes can then be implemented.
Part 7.3 will follow next week...
Freitag, 30. März 2012
Integration of legacy systems into a modern enterprise SOA (part 7.1)
Integration of legacy systems into a modern enterprise SOA - Part 7.1
7. Approach
1. Pre- and analysis phase
In a first phase the legacy application which should be integrated und the calling business process should be analysed thoroughly. With standard application the level of customer-specific changes in the application must be identified (customizing quote). Documentation and calling methods of these changes must be checked. If the customizing quote is high, it must be decided, if the use of standard adapter is still reasonable. Often, with individual customer-specific legacy systems the only way of integration is using the application data layer. It must be checked how data persistence was implemented.
The state of documentation is also very important regarding the application which should be integrated.
- do process maps and system manuals exist?
- is there documentation of data models / object models?
- are there application-specific interfaces (APIs), which can be used?
- how does the legacy system act regarding security?
- how do the components communicate between one another?
- with multi-tier architecture, are there reusable components, applications server, data dictionaries, etc. ?
- are there possible interests and issues of the operating department?
2. Planning phase
The planning phase follows the analysis phase. If needed, a new modelling of the target processes is conducted in the planning phase. This is based on the process documentation which is created in phase 1 (actual process). At that time it must be clarified how the target architecure should be composed.
During the planning phase the following topics have to handled:
- which topology will be introduced? (e.g. bus topology)
- is the use of a canonical data model reasonable and effective?
- do any standard application packages exist ("packaged integration solutions", e.g. Oracle AIA)
- do any reference archtecture exist?
- how can the user experience of the new process be improved?
- ...
Part 7.2 will follow next week...
7. Approach
1. Pre- and analysis phase
In a first phase the legacy application which should be integrated und the calling business process should be analysed thoroughly. With standard application the level of customer-specific changes in the application must be identified (customizing quote). Documentation and calling methods of these changes must be checked. If the customizing quote is high, it must be decided, if the use of standard adapter is still reasonable. Often, with individual customer-specific legacy systems the only way of integration is using the application data layer. It must be checked how data persistence was implemented.
The state of documentation is also very important regarding the application which should be integrated.
- do process maps and system manuals exist?
- is there documentation of data models / object models?
- are there application-specific interfaces (APIs), which can be used?
- how does the legacy system act regarding security?
- how do the components communicate between one another?
- with multi-tier architecture, are there reusable components, applications server, data dictionaries, etc. ?
- are there possible interests and issues of the operating department?
2. Planning phase
The planning phase follows the analysis phase. If needed, a new modelling of the target processes is conducted in the planning phase. This is based on the process documentation which is created in phase 1 (actual process). At that time it must be clarified how the target architecure should be composed.
During the planning phase the following topics have to handled:
- which topology will be introduced? (e.g. bus topology)
- is the use of a canonical data model reasonable and effective?
- do any standard application packages exist ("packaged integration solutions", e.g. Oracle AIA)
- do any reference archtecture exist?
- how can the user experience of the new process be improved?
- ...
Part 7.2 will follow next week...
Montag, 26. März 2012
Integration of legacy systems into a modern enterprise SOA (part 5 + 6)
Integration of legacy systems into a modern enterprise SOA - Part 5 and 6
5. Impact of SOA on the legacy system
If servce-oriented rules are applied while integration, the level of reusability of the components of the legacy system can be increased. By using loose coupling, both the business process and the use of the integrated component will be more flexible. Changes in processes are now even easier to implement. The complexity level of the complete system will be reduced by use of standard (integration-) components. This can also be relevant for monitoring and maintenance.
6. Ways of integration
Application integration
One of the main tasks that must be achieved is the integration of business logic, the mapping of rules and workflows. In many cases it is not sufficient to wrap existing logic publish it as a webservice. Maybe batch processes have to be transformed into a callable function. Transformation- and mapping logic must be added to the interface. Parts of the previous business process could be changed. Furthermore, transaction security must be observed and guaranteed.
Data integration
Relational and not relational data must be published on the interface. Dependant on the legacy system, an existing persistence layer must be used or even a new layer must be created. Here also transformations must be conducted at the interface to present data in a general valid format. Maybe a canonical data model should be taken into consideration.
presentation (view) integration
If access to data and application logic is not practical due to different reasons, as an alternative one can integrate the legacy system directly on the presentation layer. The aim is here to replace all terminals, which access the mainframe. The different forms, screens and menues must tapped/scanned at the mainframe and be made available as a service, e.g. in a modern JEE application. It is advisalbe to integrate the forms and menues of the legacy systems into a portal or a modern application by which they are presented to the user.
Part 7 will follow next week...
5. Impact of SOA on the legacy system
If servce-oriented rules are applied while integration, the level of reusability of the components of the legacy system can be increased. By using loose coupling, both the business process and the use of the integrated component will be more flexible. Changes in processes are now even easier to implement. The complexity level of the complete system will be reduced by use of standard (integration-) components. This can also be relevant for monitoring and maintenance.
6. Ways of integration
Application integration
One of the main tasks that must be achieved is the integration of business logic, the mapping of rules and workflows. In many cases it is not sufficient to wrap existing logic publish it as a webservice. Maybe batch processes have to be transformed into a callable function. Transformation- and mapping logic must be added to the interface. Parts of the previous business process could be changed. Furthermore, transaction security must be observed and guaranteed.
Data integration
Relational and not relational data must be published on the interface. Dependant on the legacy system, an existing persistence layer must be used or even a new layer must be created. Here also transformations must be conducted at the interface to present data in a general valid format. Maybe a canonical data model should be taken into consideration.
presentation (view) integration
If access to data and application logic is not practical due to different reasons, as an alternative one can integrate the legacy system directly on the presentation layer. The aim is here to replace all terminals, which access the mainframe. The different forms, screens and menues must tapped/scanned at the mainframe and be made available as a service, e.g. in a modern JEE application. It is advisalbe to integrate the forms and menues of the legacy systems into a portal or a modern application by which they are presented to the user.
Part 7 will follow next week...
Mittwoch, 21. März 2012
Integration of legacy systems into a modern enterprise SOA (part 3 + 4)
Integration of legacy systems into a modern enterprise SOA - Part 3 and 4
3. Previous attempts
Previous attempts like "point to point", "hub and spoke" or "batch runs" do only meet some of the demands of current architectures. Furthermore there are several drawbacks, which have to be accepted when using those. Often, these methods are only suitable to solve one problem. A wholistic, integrated method would provide an important benefit.
4. Using the SOA method for integration
To adress the previously specified troubles, it is important to identify the required functionality of the old legacy system. The target would be to provide those as services, so that they can be used by other applications. Legacy systems were often treated as a black box. The underlying business logic was ignored by the caller, so that issues like performance, security and maintenance are hard to include into the overall view. The monolithic structure / tight coupling of the legacy components prevents them from being used in a service-oriented architecture respectively its business processes.
In contrast a SOA landscape consists of a mapping of business processes and the corresponding services. Standards allow the general communication and all components should be lousely coupled, so that the advantages of this archicture (e.g. a high grade of reusability) are ensured.
One of the most important advantages of a SOA are its features for legacy enablement. The use and integration of data and logic from legacy systems considering SOA-specific rules, allows a flexible, real-time use of the legacy recources, while keeping and using the advantages, which is offered by a service oriented architecure. By applicating this strategy a big number of assets of the legacy system and the service oriented architecture can be used, to create additional benefit for your enterprise.
Part 5 will follow next week...
3. Previous attempts
Previous attempts like "point to point", "hub and spoke" or "batch runs" do only meet some of the demands of current architectures. Furthermore there are several drawbacks, which have to be accepted when using those. Often, these methods are only suitable to solve one problem. A wholistic, integrated method would provide an important benefit.
4. Using the SOA method for integration
To adress the previously specified troubles, it is important to identify the required functionality of the old legacy system. The target would be to provide those as services, so that they can be used by other applications. Legacy systems were often treated as a black box. The underlying business logic was ignored by the caller, so that issues like performance, security and maintenance are hard to include into the overall view. The monolithic structure / tight coupling of the legacy components prevents them from being used in a service-oriented architecture respectively its business processes.
In contrast a SOA landscape consists of a mapping of business processes and the corresponding services. Standards allow the general communication and all components should be lousely coupled, so that the advantages of this archicture (e.g. a high grade of reusability) are ensured.
One of the most important advantages of a SOA are its features for legacy enablement. The use and integration of data and logic from legacy systems considering SOA-specific rules, allows a flexible, real-time use of the legacy recources, while keeping and using the advantages, which is offered by a service oriented architecure. By applicating this strategy a big number of assets of the legacy system and the service oriented architecture can be used, to create additional benefit for your enterprise.
Part 5 will follow next week...
Samstag, 17. März 2012
Integration of legacy systems into a modern enterprise SOA (part 2)
Integration of legacy systems into a modern enterprise SOA (part 2)
2. What are lagacy systems?
Legacy systems are still wide-spread. Frequently they are defined as IT systems (hard- and software), which are in use for a long time in an enterprise. In the majority of cases these systems (or parts of it) do not run on up-to-date hardware and even if they do, oftentimes the software architecture is not on recent levels. Mostly present-day software and architecture standards like SOA, JEE, Multi-Tier, application server and middleware are not used.
However, those systems are an integral part of some enterprises. Usually, they even today represent their core competence and directly participate in revenue generation (e.g. mainframe, cobol, ...). In addition those systems contain huge development and maintenance effort from the past, for which reason they represent an important factor in enterprise intelligence and -experience.
The many advantages of those inherited systems are obvious. Frequently the TCO is very high, their components are tightly coupled or the architecure is monolithic and not up-to-date. Senior developer and other knowledge carrier have maybe left the company and new demands require much development effort (high "Time-to-Market"). Also the documentation is out of date. These are reasons why in many cases the management thinks about replacement or new product development, but this was refused due to cost and time issues. Also with enterprise takeovers or acquisitions an integration scenario can become necessary. In this case external legacy systems must often be added to the own SOA landscape.
As you can see, there are many reasons, why those systems should be integrated simple, fast, functional and future-proof into modern enterprise architectures (e.g. SOA). This process is called "legacy enablement".
Part 3 will follow next week...
2. What are lagacy systems?
Legacy systems are still wide-spread. Frequently they are defined as IT systems (hard- and software), which are in use for a long time in an enterprise. In the majority of cases these systems (or parts of it) do not run on up-to-date hardware and even if they do, oftentimes the software architecture is not on recent levels. Mostly present-day software and architecture standards like SOA, JEE, Multi-Tier, application server and middleware are not used.
However, those systems are an integral part of some enterprises. Usually, they even today represent their core competence and directly participate in revenue generation (e.g. mainframe, cobol, ...). In addition those systems contain huge development and maintenance effort from the past, for which reason they represent an important factor in enterprise intelligence and -experience.
The many advantages of those inherited systems are obvious. Frequently the TCO is very high, their components are tightly coupled or the architecure is monolithic and not up-to-date. Senior developer and other knowledge carrier have maybe left the company and new demands require much development effort (high "Time-to-Market"). Also the documentation is out of date. These are reasons why in many cases the management thinks about replacement or new product development, but this was refused due to cost and time issues. Also with enterprise takeovers or acquisitions an integration scenario can become necessary. In this case external legacy systems must often be added to the own SOA landscape.
As you can see, there are many reasons, why those systems should be integrated simple, fast, functional and future-proof into modern enterprise architectures (e.g. SOA). This process is called "legacy enablement".
Part 3 will follow next week...
Abonnieren
Posts (Atom)