Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Swift Method: A Framework for Software Modernization Using DDD

The Swift Method: A Framework for Software Modernization Using DDD

Leia em Português

The Swift Method is a set of techniques for analyzing complex legacy systems, and determining the work required to gradually modernize key components or the whole system. Shaun Anderson, principal solutions architect at Pivotal Software, introduced the Swift Method to attendees at Explore DDD 2019, and gave examples of how the five tools and techniques have been used to successfully update enormous (up to 5 million lines of code) mission-critical software systems.

Anderson believes asking the question, "What is modernization?" has very different answers depending on who you ask. Technical leaders focus on the "how," defining a modern system in terms of tools and technologies, like Kafka and containers. Conversely, business stakeholders look at "why" modernization is important, looking at business results, pain points, and costs. The Swift Method considers both these viewpoints, using exercises that incorporate both non-technical, top-down and technical, bottom-up analysis.

When working with clients, Anderson concluded that having a global definition of modernization wasn't important; a team needs to define what it means for them. This requires good communication and shared understanding of the system and the challenges. For the Swift Method, Event Storming is used to make sense of the chaos and complexity of legacy software and the associated business processes by discovering clumps of business events that are likely service candidates.

The notional service candidates are the starting point for the Boris Exercise, which uses graph theory to determine the way "the system wants to behave." Similar to Event Storming, Boris uses a lot of sticky notes, one for each domain, node, or service, placed on large butcher paper. Whiteboard tape is used to connect the sticky notes to indicate communication paths between nodes, thereby creating a visual map of the system. At first, the Boris Exercise should be used to find the notional architecture, by following the "happy path" and thinking about thin slices through the system from a process perspective. Later iterations can be used to walk through special cases, as the 80% case provides the desired clarity without getting too cluttered. 

The results of the Boris Exercise are captured using a rapid documentation technique called SNAP-E. For each service, the corresponding SNAP-E consists of documentation on five categories: APIs, Data, External Systems/UI, Stories and Risks. The goal is to capture the information, and avoid analysis paralysis.

After the analysis and documentation has been completed, the fourth step is to start identifying technical patterns that can be used. By again thinking about "how the system wants to be designed" and working towards modernization, this often includes anti-corruption layers for monolith decomposition, CQRS and data storage patterns, asynchronous messaging, and/or microservices.

The final step in the Swift Method is to create a backlog of the work to be done. The knowledge captured in the SNAP-Es is combined with the desired technical patterns, to create a set of stories, and then prioritize them.

To avoid over-analyzing the problem, the team should pause the Swift Method once they are able to create a prioritized backlog. As modernization work begins, the team can periodically re-visit the process to work on subsequent phases.

The Swift Method is also useful for greenfield applications. Those familiar with DDD will recognize the goals of identifying a core domain, breaking down a complex system into bounded contexts, and using a ubiquitous language to improve communication and collaboration.

Anderson said the Swift Method came about partially due to "constructive laziness." When he was brought in to help modernize a mainframe system, the sheer size of the codebase meant trying to learn about a legacy system by reading the code was impractical. Event Storming got everyone in the room to also avoid focusing on the code, and think about the big picture. 

After the conference, InfoQ sat down with Anderson.

InfoQ: How long have you been using the Swift Method?

Shaun Anderson: It started about three years ago. Since then, we've used it successfully with several Fortune 500 companies.

InfoQ: Were all those customers trying to modernize mainframe systems?

Anderson: No. Some were mainframes with a lot of COBOL. Others were large J2EE or WebSphere systems. We've also used it for greenfield scenarios. The entire process is programming language agnostic.

InfoQ: What guidance do you have for someone trying to facilitate a Swift session?

Anderson: Sometimes the facilitator will see the solution faster than other people in the room. It's very important to let the team get there on their own. This creates a better sense of ownership of the solution, and avoids the mindset of, "the consultant told us to do this."

InfoQ: If you sometimes see where the team is headed, have there ever been any surprises or unintended consequences?

Anderson: I've seen teams bring in executives and shown them the resulting diagrams on the wall. It's a very useful way of explaining how complex systems work, and where there are major dependencies and pain points.

InfoQ: Is the purpose to find the pain points?

Anderson: That isn't an explicit purpose, certainly not to the extent that it can be with other Event Storming sessions. However, they usually show up, and sometimes where people don't expect. If you were to ask someone, their opinion will always be biased. The Boris Exercise may show them that the problem they face is actually due to a dependency they didn't realize existed.

InfoQ: Where did the ideas and names of the exercises come from?

Anderson: The idea for The Boris Exercise came from seeing three skeins of yarn sitting on the desk of a COBOL programmer who liked to knit. The end result is something that looks like a spider web. We eventually replaced yarn with whiteboard tape. The name comes from the song "Boris the Spider," by The Who.

Snap-E is a quick method creating documentation "in a snap." Some people assumed there was an acronym, so we decided on "SNAP, Not Analysis Paralysis, Enhanced."

Rate this Article