Skip to content

Integrating with legacy applications

Practice · Chapter 14

Architects may need to integrate a legacy app with another application. If you own the legacy system, some refactoring may be required first to modernize it to an integrable state. Several considerations follow.

  • First decide whether integration is even necessary — it may be easier to migrate the needed functionality out of the legacy system instead.
  • Weigh the amount and complexity of functionality needed: a lot of highly complex functionality is costly to migrate, so integrating and keeping the legacy system may be cheaper.
  • Weigh long-term goals and the legacy system’s expected remaining lifetime: if retirement is near, it may make more sense to start that process than to invest in an integration.

Match the integration style to business drivers and requirements, and to knowledge of the current environments:

TypeTimingNotes
Real-timeImmediate — an action in one system instantly triggers anotherMore complex and expensive to implement.
Near real-timeQuick, but measured in minutes rather than secondsSufficient when instant action isn’t required.
BatchHours or even daysSchedulable during off-peak hours; simplest and least disruptive.
  • Integrating a new app with a legacy one often duplicates functionality across both. Decide which system owns each shared responsibility, and identify differences in shared business logic (those differences inform the decision).
  • Expose and share redundant logic so it lives in one place — ensuring consistency and raising quality and maintainability (maintain and test once).
  • Combine data from disparate sources meaningfully: understand what the data in each system represents and whether a given piece means the same thing in both.
  • Data mapping may be needed to transform data between systems. Remove data redundancy where possible and decide which system owns which pieces of data.
  • Software Architect’s Handbook (Packt, 2018), Ch.14 “Integrating with legacy applications”, pp. 1069-1073.