Extension-based architecture for legacy RPA modernization

Our customer, an enterprise-level business leader, was utilizing a system built upon monolithic architecture. Quite outdated, while handling critical operations, their software heavily struggled with modern API changes and ever-evolving business needs and objectives.

The maintenance was getting extremely expensive, with spending almost reaching the system’s initial price. Compatibility issues, security-related vulnerabilities, hard-to-track bugs, and unavailable software developers pushed towards immediate modernization – without breaking the bank.

The system was implemented to design and manage workflow templates with predefined workflow steps. These comprise data syncing, file handling, smart analytics, email notifications, and reporting among others – all within one software.
Any updates and modifications typically caused unexpected disruptions, slowing down business operations.

To resolve these breakdowns, we delivered an application specifically designed at handling SAP-related steps. The service was using a flexible, extension-based architecture, mostly inspired by the Visual Studio Code model.

Now, instead of modifying the codebase, we integrate new features as completely independent extensions—each with its own process boundary and logic.

Our team:

• Built a standalone application to handle SAP-related steps
• Designed an extension-based model
• Added a “workflow catalog” to the legacy application for dynamic workflow discovery and execution
• Created an IPC layer by using input/output streams
• Defined consistent RPC endpoints for all workflow steps
• Built robust integration tests to ensure backward compatibility

Making a monolith extensible

The system wasn’t designed for modularity, which complicated component integration without malfunctions. 

We resolved the challenge by integrating extension-based design to override specific steps by performing:

• The refactoring of the legacy application to support built extensions
• The conversion of the SAP application
• Integration tests to ensure backward compatibility 

Bridging technologies

The new SAP handler was written by using modern technology, which obstructed overall interoperability.

We resolved this problem:

• Running the SAP handler as a separate application to decouple it from the system
• Using standard input/output streams to enable communication between the components
• Introducing a communication layer to enable smooth integration 

• Increased savings – the extensions are reusable between products within the same domain
• Reduced complexity – separated functionality simplifies maintenance and troubleshooting
• Greater flexibility & scalability< – new features are added without major codebase changes
• Better stability – new features are executed without affecting legacy components