When embarking on a journey to break up a monolith and modernize it into microservices, it can be overwhelming to know where and how to start. As developers, we rarely know all the potential impacts of changing a single component, let alone dozens of components. As architects, we often foresee such an insurmountable mountain of discovery and untangling of spaghetti code that starting from scratch seems easier. As product managers, we often take for granted that the current behaviors in a system already fulfill the needs of the business. We often don’t ask whether or not the current system was coded in a way that actually addresses the pain points of the user.
As if these challenges weren’t enough, you often want to also change the way teams work to be more aligned with agile practices. You’re modernizing not only the code, but also the way that people work. With all of these challenges, it’s no wonder that teams only embark on these journeys when they are forced to do so by external forces.
What if there were a method that teams could employ to lighten the burden and risks of modernization? There is!
The Swift Method, developed by Pivotal/Tanzu Labs, is a set of lightweight techniques that reduce the burdens and risks of modernization. Swift uses agile and domain-driven design (DDD) principles that help teams plan just enough to start modernizing software systems. It includes three core activities—event storming, Boris, and SNAP—that break down a system of systems. A main goal of these activities is to develop a notional architectural plan that uncovers how the system wants to behave, within the context of the business goals.
In this series, we’ll dive into how a team of architects, developers, and product managers approach modernizing monoliths using the Swift Method. We’ll provide some examples of questions each role might ask and how they contribute at different stages of the modernization process.