Swift Monolith Modernization

Swift Method Overview

Marc Zottner & Lizz Smullen

What is Swift?

The Swift Method is a suite of highly effective, time-saving practices that are proven to help development teams who want to build highly scalable software or who are stuck in the modernization of existing monolithic applications. Instead of spending months doing analysis work, the team moves forward with a lean development plan that they can expect to bring new tested features in production at the end of 4-10 one week iterations.

The Swift practices collaboratively align the stakeholders of an application with implementation objectives, desired functionalities, and high-level design. A stakeholder is any person with a vested interest in releasing a successful software project, and can be administrators, designers, developers, directors, product managers, and project managers.

The information that the stakeholders share is going to prove instrumental in helping you make informed decisions on how to organize development teams, and how to prioritize stories from a business and technical perspective. Swift jumpstarts the work of turning an idea or a monolith application into a highly distributed, modern application. In the case of a legacy system, you decompose and rewrite a monolith from the ground up by figuring out how it wants to behave. Old and new systems co-exist while the legacy system is progressively broken down and its parts rebuilt. This method has been developed over time by Pivotal/Tanzu Labs practitioners, especially by Shaun Anderson.

How Does Swift Work?

Swift helps you to successfully plan projects that significantly reduce development time using a series of activities including Event Storming Light, Thin Slice definition, a Boris Exercise, and SNAP.

These activities are opinionated and well defined: they have been fine tuned through dozens of conducted real-world projects. While it’s best to stick to defined activities for your first try, the Swift approach is meant to be adapted to the needs of your endeavor.

The success formula of Swift lies in its highly-collaborative nature (intrinsic alignment), while focussing on the future (and not the past) of the app by quickly shaping its notional architecture, and just getting started (constructive laziness).

• Notional architecture

  Notional architecture drafts the high-level design of the application to be built. It focuses on the communication flows between the core business capabilities and refrains from embedding any form of technological aspects. While aligning all stakeholders behind a big picture with a simple representation depicting how the system wants to behave, notional architecture eliminates weeks and months of analysis and conceptual work.

• Future over past

  Swift focuses fully on the desired application, and the future rather than its past. While many learnings on functionality and user experience originate from previous insights, spending too much time on the past is a trap that often prevents any progress. In the engineering process, you spend most of your time considering how the application would be built from scratch today by a fast-paced tech startup, rather than by capitalizing on the entirety of existing code and specifications.

• Collaboration first

  Bringing together all stakeholders of the application lifecycle to effectively align, collaborate, ideate, and exchange is at the heart of the swift methodology. The stakeholders transform from people with individual ideas, to people who collectively discover solutions to problems. No one feels left out because everyone sees how they fit into the big picture.

• Constructive laziness

  Constructive laziness recognizes that it’s OK to not know everything upfront about an enterprise system, especially in the case of large systems that are constantly evolving. No one can know everything. In the end, perfect is the enemy of good. How do you escape the analysis-paralysis trap aiming to craft the perfect meta-architecture with completely detailed specifications? By taking a leap of faith, and accepting that a realistic way forward implies starting small, working on one scenario part of the big picture first, and evolving incrementally.

Sequence of Activities

It’s OK to leverage each practice individually, but you’ll get better results by applying them in the following sequential order:

1. Quantify targeted outcomes for goals and non-goals
2. Quickly understand the desired business functionality using Event Storming Light
3. Identify business capabilities as service candidates
4. Select a meaningful starting point: a thin slice of functionality
5. Use Boris notional architecture to find out how the system wants to be designed
6. Document each business capability instantly with SNAP
7. Explore and match technical patterns
8. Create a prioritized work backlog
9. Develop iteratively tested and working code

The steps come together, as depicted in the following diagram:

The following sections describe the purpose of each practice, how long each practice takes to complete, group activities for the stakeholders, and the positive outcomes to expect.

1. Quantify targeted outcomes for goals and non-goals

Purpose	To capture the goals and non-goals that set the direction for the project, and to ensure that ongoing progress continues in an intended direction by becoming a North Star for your project or program. This is a core prerequisite to enforce alignment between new architecture and efforts with the desired business outcomes.
Duration	1 - 2 hours
Activities	Conduct an interactive workshop about goals and non-goals.
Outcomes	A list of goals and non-goals agreed upon and prioritized by the stakeholders.

2. Quickly understand the desired business functionality using Event Storming Light

Purpose	To interactively explore the desired business functionality of an application. The practice fosters clarity and aligns all stakeholders on the future application by collaboratively crafting a commonly understood model and language.
Duration	1 - 2 days
Activities	A bespoke, simplified variant of the Big Picture Event Storming that you can use to model the business domain behind your application and leverage a common language for different tribes.
Outcomes	A non-exhaustive, non-technical, comprehensive model of the business functionality covered by the system that you want to build. The model includes business events, domains, and capabilities. It is typically complemented by a glossary covering abbreviations and the meaning of specific business terms.

3. Identify business capabilities as service candidates

Purpose	To define the boundaries between the different business domains, and to identify potential, separate service candidates for the new system.
Duration	1 hour
Activities	Leverage pivotal events and domain boundaries to map events to a service capability.
Outcomes	Named groups of events belonging to the same business capability. The groups are known as service candidates.

4. Select a meaningful starting point: a thin slice of functionality

Purpose	To identify and select a first business narrative to start modernizing out of everything your monolithic application is doing. This business narrative is referred to as a “thin slice” of functionality because it reflects a small functional piece of the whole cake: your monolith application.
Duration	1 - 2 hours
Activities	Cut the monolithic business cake and pick a sweet piece to start the modernization work. Prioritize practices like dot voting, and pain points clustering, while keeping the previously defined goals and non-goals that are typically leveraged here.
Outcomes	A first well-defined business narrative (“thin slice” of functionality) is identified and framed.

5. Use Boris notional architecture to find out how the system wants to be designed

Purpose	To design the notional, technology-agnostic architecture of the desired system that will be used as a basis for the implementation for the selected slice of functionalities.
Duration	2 - 4 days
Activities	Follow the business narrative covered by the selected thin slice to model and draw the communication between the previously identified business capabilities of the target system. This guided exercise uncovers needs in terms of APIs, data, communication and synchronicity. It also helps to capture relevant business logic, ownerships, cross-cutting concerns, and risks for the implementation of a thin slice.
Outcomes	Documented communication model between identified business capabilities that reveals the likely target architecture of the system.

6. Document each business capability instantly with SNAP

Purpose	To quickly capture and structurally document the information discovered during the Boris exercise for each business capability.
Duration	Occurs in parallel to the Boris exercise.
Activities	Pre-filled structured templates (AKA SNAP-sheets) for each relevant business capability are filled in real-time during the Boris exercise.
Outcomes	One structured documentation sheet for each business capability covering the following categories: APIs, Data, External Systems, UI, Stories, and Risks.

7. Explore and match technical patterns

Purpose	To preselect known and missing technical design patterns you could apply while building in the drafted notional architecture.
Duration	1 - 2 hours
Activities	Identify recurrent patterns that are documented in your library or missing ones that should be elaborated on. Examples include Anti-Corruption Layers (ACL), asynchronous communication with messaging, and data storage (SQL/NoSQL).
Outcomes	One list of patterns to either be reused during the implementation, or developed to solve specific repeating issues.

8. Create a prioritized work backlog

Purpose	To create a prioritized agile backlog of work to structure the implementation and to understand the interdependencies between the required activities.
Duration	1 - 2 days
Activities	By going through the previous steps, a list of stories and tasks will be documented in the SNAP sheets. Creation of the backlog is a matter of prioritizing the stories based on the highest priority, thin slice of functionality. This step is also used to formalize the stories by mapping them to any technical patterns that are defined. An “Objective and Key Results” (OKR) exercise can be conducted at this stage to align priorities on goals.
Outcomes	Prioritized a backlog of work.

9. Develop iteratively tested and working code

Purpose	To turn the desired notional architecture into tested, running code by iterating on the backlog of work.
Duration	Several 1-week iterations.
Activities	Iterate on the backlog of work to take low-level design decisions, document learning, apply technical patterns to use, and implement user stories.
Outcomes	Tested and working code running on production implementing the desired system.

Next

In the upcoming sections of this learning path, you are going to learn many more insights and best practices that are essential to successfully conducting each step of the Swift method.