Evolving legacy software architecture

Written by Anders Marzi Tornblad 19 June 2023

This is part 7 of the Getting into software architecture series. If you haven't read the first part, here it is: A primer for emerging software architects

So you've got a legacy system. It's served your organization for years, maybe even decades. It's been patched, updated, extended, and reconfigured more times than you can count. And while it's still serving your business in some capacity, you're starting to feel the strain.

The performance may be lagging, it might not be compatible with the newer technologies you want to adopt, or maintaining it could be becoming a nightmare. Whatever the reason, it's clear: your legacy system needs to evolve, and it's up to you and your team to guide it.

In this article, we'll delve into how we can evolve legacy systems through software architecture strategies. We'll explore approaches like refactoring, modularization, and migration to cloud-native architectures. In particular, we'll examine a refactoring pattern known as the Strangler Fig pattern.

Encapsulation

If we're to see software architecture as a growing city, encapsulation would be the building codes and zoning laws that keep everything running smoothly. It's a vital principle that ensures the city's structures — or in our case, software components — can interact cohesively and effectively.

In essence, encapsulation is about bundling related data and procedures into cohesive units — components or modules — and exposing a clear interface for interaction. This approach is like packing your belongings into clearly labeled boxes during a house move. Each box holds items that belong together, and you can tell what's inside without having to look through the contents.

So, how does encapsulation fit into the evolution of legacy systems?

Encapsulating Legacy Systems

One way to use encapsulation when dealing with legacy systems is to 'wrap' older code with a new interface. This interface serves as a sort of translation layer, allowing the old code to interact with other system components in a more modern and efficient manner.

This technique might involve creating APIs or wrappers that 'hide' the legacy system behind a more modern façade. For example, you might create a RESTful API that translates incoming HTTP requests into calls that the legacy system can understand, then translates the system's responses back into HTTP.

The beauty of this approach is that the rest of your software ecosystem doesn't need to know anything about the underlying legacy system. It simply interacts with the modern, intuitive API, thereby reducing the risk of dependencies and integration issues. This can be a first step towards building more modern solutions, if the wrapper API you create is designed in a future-proof way, and not just blindly recreate the legacy interface with new technology.

Encapsulating Business Logic

Another approach to encapsulation in legacy systems focuses on the business logic — the rules and procedures that define how your system behaves.

In many legacy systems, business logic can become deeply entwined with the system's infrastructure code, making it difficult to change one without affecting the other. By abstracting this business logic away from the older components and encapsulating it within its own module or service, you can provide a fresh interface that's easier to maintain and adapt to evolving business needs.

Agile and Encapsulation

Encapsulation aligns perfectly with the Agile methodology of software development. Agile emphasizes iterative, incremental updates rather than huge, monolithic changes, and encapsulation allows us to do just that — to isolate and evolve pieces of our system independently, one at a time.

Working on encapsulation in Agile sprints allows you to frequently assess and reassess the system's architecture and make necessary changes in small, manageable chunks. Each sprint can focus on encapsulating a specific piece of the legacy system, which then becomes a self-contained unit that can be updated, tested, and deployed independently from the rest of the system.

Leading the Encapsulation Process

Leading an encapsulation effort requires a fine balance of technical skill and leadership prowess. Here are a few practical tips to help you navigate the process:

Understand your system: Before you can encapsulate, you need a deep understanding of your system's architecture and business logic. Spend time getting to know the intricacies of your legacy system and identify which components would benefit most from encapsulation.
Prioritize: Not all parts of the legacy system need to be encapsulated at once. Prioritize based on factors like business value, complexity, and risk.
Collaborate and communicate: Encapsulation isn't a one-person job. Encourage collaboration and open communication among your team members. Make sure everyone understands what encapsulation is, why you're doing it, and what the benefits will be.
Embrace testing: Testing is critical to ensuring your encapsulated components work as expected. Invest in robust testing frameworks and practices to catch any issues early.
Celebrate progress: Every piece of the legacy system successfully encapsulated is a step forward. Celebrate these milestones to boost team morale and keep the momentum going.

Remember, evolving a legacy system is a marathon, not a sprint. Encapsulation is just one tool in your architectural toolkit, but it's a powerful one. By thoughtfully applying the principle of encapsulation, you can increase your legacy system's maintainability, reduce dependencies, and pave the way for a more modern, agile software architecture. Happy encapsulating!

Replatforming

Replatforming, in essence, is like moving home. It involves picking up your software application from its old, perhaps somewhat antiquated surroundings, and relocating it to a swanky, new environment. In the digital realm, this could often mean moving from a traditional on-premise data center to the cloud.

Why Replatform?

Just like a growing family might need a larger home, a legacy system might also outgrow its initial environment. And with growth comes the need for scalability, reliability, and a performance boost — qualities that a cloud environment is designed to provide.

Migrating to the cloud not only accommodates growth, but it also offers a platform compatible with modern technologies. This means that your system can interact more smoothly with new tools, frameworks, and services. Plus, it prepares your application for further modernization down the line, such as adopting microservices or serverless architectures.

While replatforming may sound like a radical transformation, it's crucial to note that it doesn't necessarily involve changing your application's codebase. The application's functionality remains the same; it's just living somewhere new.

Agile Advantage in Replatforming

Replatforming fits neatly into an Agile framework. Rather than a massive one-time migration, which can be disruptive and risky, an Agile approach would favor moving components of the system incrementally, maintaining business continuity, and learning from each move.

This 'step-by-step' method allows teams to assess and resolve potential issues at each stage, instead of discovering a mountain of problems after a full-scale migration. It's a safer, more manageable approach that aligns with Agile's core principles of iterative development and continuous improvement.

Leading Replatforming Efforts: Key Considerations

Define Your Goals: Before you start any migration process, be clear about what you want to achieve. Is it scalability? Lower costs? Better performance? Having a clear understanding of your objectives will guide your decision-making throughout the process.
Know Your Application: Thoroughly assess your application before moving it. Identify potential issues that could occur during the move and plan how to address them. Knowing your application inside and out will make the move smoother and less stressful.
Choose the Right Cloud Platform: There are multiple cloud platforms out there, and they're not all created equal. Research and choose a platform that suits your needs, budget, and future plans.
Develop a Migration Plan: Moving an entire application is a big task. Break it down into manageable parts, prioritizing based on complexity, risk, and business value. Then, tackle each part one at a time.
Test, Test, Test: Testing is vital during replatforming. Ensure every component functions correctly in the new environment before moving on to the next. This approach helps maintain business continuity and reduces the risk of post-migration issues.
Communicate: Keep all stakeholders in the loop. Regularly update them on the progress, any issues encountered, and how those issues are being resolved. Transparency builds trust and makes the entire process smoother.

Replatforming is a significant step in the evolution of your legacy system. It's an opportunity to boost performance, enhance scalability, and prepare your application for a future of continued growth. Remember, just like moving homes, it may come with a fair bit of heavy lifting and unexpected hitches, but the benefits of a new, improved environment make it a journey worth taking. So, lace up your digital moving boots, and let's get replatforming!

Refactoring and the Strangler Fig Pattern

Just as nature has its ways of renewing and replacing the old, software development has its methods of breathing new life into legacy systems. Two such approaches are refactoring and the Strangler Fig pattern. Let's delve into these methods and see how they help modernizing legacy systems.

Refactoring

Refactoring is essentially the act of improving your code without changing its behavior. It's like reorganizing your kitchen - you're not getting new ingredients or equipment; you're just optimizing their placement for more efficient use.

In the software world, this might involve simplifying complex code structures, renaming variables for clarity, or breaking down large functions into smaller, more manageable ones. The idea is to make your code cleaner, more understandable, and easier to maintain, without altering what it does.

And like an Agile chef continually refining their cooking process, refactoring should be a constant activity in Agile software development. As you add new features or fix bugs, take the opportunity to clean up and streamline your code. Remember, small, regular improvements often lead to significant long-term benefits.

If you want to improve your refactoring skills, I recommend you take a look at The Gilded Rose Kata, a structured approach to refactoring training, initially created by Terry Hughes, and further refined by Emily Bache. It emphasizes test-driven development, proven refactoring patterns and an evolutionary approach.

The Strangler Fig Pattern

Nature often provides us with good metaphors, and software architecture is no exception. The Strangler Fig pattern is a refactoring strategy inspired by the growth of the strangler fig tree.

The strangler fig starts as a seed high up in the branches of a host tree. Over time, it grows and extends its roots around the host tree, eventually replacing it. In software terms, you start by building new components alongside your legacy system, reimplementing its functionality. These new components gradually take over responsibilities from the old system until, eventually, they replace it entirely.

The beauty of this approach is that the system continues to operate as normal during this process. If a new component doesn't work as expected, you can simply switch back to the old one, reducing the risk and potential disruption.

Leading the Refactoring and Strangler Fig Pattern Process

Identify Refactoring Opportunities: The first step in refactoring is to understand where improvements can be made. Tools like static analyzers and linters can help identify areas of your code that could benefit from refactoring.
Start Small: Start by refactoring small parts of your codebase. This is where the Agile principle of iterative, incremental changes shines. Small changes are easier to manage and less likely to introduce bugs.
Automate Testing: Automated testing is crucial during refactoring. Tests give you the confidence to refactor without fear of breaking existing functionality.
Strangler Fig Approach: Identify parts of your system that could benefit from the Strangler Fig pattern. These might be parts that are particularly difficult to maintain or are due for significant changes.
Incrementally Replace Components: Replace components one by one, testing each new component thoroughly before moving on to the next.
Communicate: Keep your team and stakeholders informed about your refactoring and Strangler Fig efforts. Explaining what you're doing and why can help gain their support and understanding.
Continually Learn and Adapt: Like everything in Agile, refactoring and the Strangler Fig pattern are about continual learning and adaptation. Reflect on what's working and what isn't, and don't be afraid to adjust your approach accordingly.

Refactoring and the Strangler Fig pattern offer powerful ways to improve and modernize your legacy systems. They reflect the Agile principles of continual improvement and adaptive planning, helping you transform your systems increment

ally and manageably. Happy refactoring and may the growth of your software be as steady and reliable as that of the Strangler Fig!

Re-architecting

Re-architecting might sound overwhelming, but in essence, it's similar to home renovation. Imagine you're in a house where the rooms no longer serve their intended purpose — the kitchen's too small, the living room can't accommodate your guests, or maybe, the building lacks the necessary insulation. You don't want to move, but it's clear that mere reorganization won't suffice. So, you decide to make structural changes, knocking down walls, adding extensions - fundamentally changing your home's architecture.

In software terms, re-architecting involves a similar approach. Sometimes, legacy systems reach a point where the architecture doesn't support business needs, or it's incompatible with modern technologies. In such situations, refactoring or minor adjustments might not be enough. You need to change the system's architecture, its underlying blueprint.

Often, this transition might involve moving from a monolithic architecture to a more modular architecture. A monolithic system is like a big old house where everything is interconnected. Changes in one area could impact others, making the system difficult to scale and maintain. On the other hand, a modular architecture is like a modern apartment complex, with independent units (services) that can be scaled, updated, or replaced individually. This architecture enhances scalability, resilience, and can accelerate development by enabling teams to work on different services simultaneously.

The Agile Intersection with Re-architecting

Agile practices align well with re-architecting. Instead of a complete, one-time overhaul (which can disrupt business operations and introduce a significant risk), Agile encourages incremental changes, one piece at a time. You don't renovate the entire house in one go; you work on one aspect at a time. You move one wall, you rewire the electricity, you add insulation where it is needed. The same principle applies to re-architecting software systems.

Agile practices also promote learning and adaptation. By implementing changes incrementally, teams can learn from each iteration, adapt the architecture based on these learnings, and gradually shape a system that's closely aligned with business needs.

Leading Re-architecting Efforts

Assess the Current State: Understanding your existing architecture is the first step. Identify the bottlenecks, areas of complexity, and limitations that are driving the need for re-architecting.
Define Your Goals: Clearly articulate what you want to achieve through re-architecting. Is it to improve scalability, enhance resilience, or increase development speed? Clarity in objectives will guide your architectural decisions.
Design the Target Architecture: Draw a blueprint of your target architecture, bearing in mind your goals. This might involve exploring architectural styles like microservices, event-driven architecture, or serverless.
Develop an Incremental Transition Plan: Plan your transition in a way that each increment delivers value and doesn't disrupt your operations. This could involve starting with less critical or standalone services, and gradually moving to more complex ones.
Test Continuously: Re-architecting involves significant changes, so rigorous testing is crucial. Each component or service should be thoroughly tested before being integrated.
Communicate and Collaborate: Re-architecting is a team effort that affects various parts of the organization. Regular communication, collaboration, and feedback loops with all stakeholders are key.
Learn and Adapt: Learn from each iteration and be ready to adapt your plan and design based on these learnings.

Remember, re-architecting is a journey, not a one-time event. It's a process of continual evolution, where you learn and adapt as you incrementally transform your system's architecture. Embrace the challenge, enjoy the journey, and watch your legacy system transform into a more modern, agile, and resilient structure that's ready to meet the ever-evolving business needs. So, don your architect's hat and start laying the blueprint for your new digital edifice!

Rebuilding and Replacing

At times, the most pragmatic approach to dealing with legacy systems is either rebuilding them from scratch or replacing them entirely with commercial solutions. It's like having a dilapidated house; you might decide to demolish and rebuild, or you might choose to move into a new, fully-furnished home. Each approach comes with its unique considerations and implications. Let's unravel these two strategies and see how they intersect with Agile methodologies.

Rebuilding

Rebuilding means recreating your legacy system from scratch using modern technologies and techniques. It's a bit like building a new house; you keep the essence, the memories of the old house, but create it anew with contemporary designs and materials.

Rebuilding gives you a fresh start, unencumbered by the constraints and complexities of the old system. It offers an opportunity to rethink your architecture, choose modern, more efficient technologies, and redesign your system to be more aligned with your current and future business needs.

However, it's crucial to remember that rebuilding can be time-consuming and expensive. It's a significant undertaking that requires a considerable investment of resources. You're starting from scratch, which means designing, coding, testing, and deploying an entirely new system. There is a real risk of missing some important aspects, as legacy design decisions are often not documented. Also, there can be implicit and tacit knowledge about the business domain that exists only as implementations in the legacy code base. Recapturing enough of the legacy knowledge to be successful in rebuilding a system can prove a challenge.

In Agile terms, rebuilding doesn't mean creating the new system in one big bang. Agile promotes an incremental, iterative approach. You start by building the most critical features in the form of a Minimum Viable Product, you test, get feedback, and gradually build the rest of the system over multiple iterations. This approach reduces risk, provides early value, and allows for continual learning and adaptation.

Replacing

Replacing, on the other hand, involves substituting your legacy system with a commercial off-the-shelf (COTS) software or Software as a Service (SaaS) solution. It's like moving to a new, fully-furnished house that's ready for you to live in.

This strategy can be a practical option if there's an available solution in the market that fits your business needs and processes. The advantages include quicker implementation, lower development cost, and often, a solution that's been tested and improved upon over time.

However, the flip side is that these solutions might not be a perfect fit for your unique business needs. They may require you to adjust your processes to fit the software, which could lead to inefficiencies or reduced productivity. It's crucial to carefully evaluate potential solutions, considering their fit, flexibility, cost, and the vendor's reputation and support.

Navigating the Rebuilding and Replacing Process

Evaluate Your Needs: Understand your current system and business needs. Identify the gaps in your legacy system and the requirements that a new system or commercial solution should meet.
Consider Your Resources: Assess your budget, timelines, and technical capabilities. Rebuilding requires significant technical resources and time, while replacing involves a financial investment and possible recurring costs.
Explore the Market: If you're considering replacing, explore the market. Look for solutions that are close fits to your needs, have good reputations, and come with solid vendor support.
Agile for Rebuilding: If you're rebuilding, adopt an Agile approach. Prioritize your features, build incrementally, and continually test and gather feedback.
Integration Considerations: For both rebuilding and replacing, consider how the new system will integrate with your existing systems. Integration challenges can cause significant disruption and inefficiency.
User Training: Whichever path you choose, user training will be crucial. Ensure your users are adequately trained and supported during the transition.

Whether it's rebuilding or replacing, both strategies come with their unique challenges and benefits. It's like choosing between building a house or moving into a new one. It's a significant decision, and one that should be made thoughtfully, considering your unique needs, constraints, and future aspirations. So, carefully consider your options, and choose the path that best paves the way for your software evolution.

Final Thoughts

Modernizing legacy systems is no easy task. It requires a deep understanding of the system, its role within your business, and the technologies that can support its evolution. It's a journey of change, and like all journeys, it's best taken one step at a time.

By applying principles like encapsulation, and strategies such as refactoring, re-architecting, and replatforming, we can gradually transform our legacy systems, enhancing their performance, compatibility, and maintainability.

As software architects, we're guides to evolution, helping our organizations adapt and grow. And with the right approaches in our toolkit, we can ensure that our legacy systems don't get left behind, but instead, transform into platforms that support the future of our businesses. So, let's embrace the challenge and start shaping the evolution today!