The “How-To” of automation and legacy transformation to impact your bottom line

The word “Legacy” often has unhappy connotations of being “outdated” and “high maintenance”. While this may be partially true, the business rules & transactions built into your legacy, over many years, are still highly relevant and valid. Your legacy assets, often become your core business differentiators. A few ways to get more value out of legacy would be to:

• Wire them together in new ways
• Make them more accessible to customers and partners
• Combine them with new capabilities
• Make them more scalable

A cloud native application model offers you building blocks that help you achieve the above four points and thus transform legacy. The key components of such a model are Containerization, Microservice based Architecture, Automatic Scalability and System Observability.

Typically, legacy applications can be categorized into one of three categories listed below:

	In-house developed applications, built on outdated technology that is expensive to maintain, not scalable, with non-availability of skills for feature evolution. These systems severely impact time to market. In most cases, they are not integration-friendly, as they support outdated interfaces.
	Third-party, out-of-the-box business applications, that were typically procured several decades ago. The vendor might have stopped developing new features and the systems are nearing sunset stage. Such applications are mostly monolithic in nature. They tend to be black boxes, with data and functions not exposed in a granular fashion.
	Business critical applications that are fully functional but built on legacy hardware and operating systems such as Mainframes. The challenge with these applications is to make them integration-friendly and scalable through API-enablement.

Factoring in the above scenarios, we formulated a legacy decomposition process to help put a method to the madness, as illustrated in Fig 1: Legacy decomposition flowchart:

Not all capability from legacy fit into the microservices architectural model. Infact, it isn’t even a best practice to move all capability. When we decompose legacy, we identify application components and data that can be containerized. With a deliberate and careful data migration strategy and decomposition, a monolith can be split into a set of microservices. Parts of the monolith that cannot be decomposed is retained until it is re-engineered or replaced with a third-party product or a SaaS application. If the retained part exposes interfaces, it can be APIenabled as-is, using an integration tool. The three models of co-existence and migration are shown in Fig 2: Models for legacy and cloud native to co-exist