.jpg)
SWIFTBIRD
THE SWIFT METHOD
The question “What is modernization?” is answered differently depending on who you ask.
Engineers, Developers and Technical Architects tend to think from a technical nuts and bolts perspective (the “how”) and, therefore, tend to look at modern technologies such as Cloud Foundry, Spring Boot, Steeltoe, Kafka and containerization as the definition of a modern application. But thinking primarily from this perspective often omits the question of “why?” and can introduce artificial constraints. The vision or thinking about art of the possible may be missing.
Conversely, when Executives, Business Analysts and Product Owners define “modern” they look at the business results and the pain points (the “why”). Product Owners and Executives tend to think in terms of pain such as time to market, MTTR, regulatory concerns and especially cost. This perspective alone tends to lead to “silver bullet” solutioning and ill-informed prioritization of work and resources -- or worse, inaction.
Assumptions are often made when communicating between these different flavors of viewpoints leading to systems missing the mark.
The Swift Method of Modernization helps bridge the gap in understanding between the non-technical, top down, way of thinking and the technical, bottom up thought process. The end result is an architecture that maps to the way the system “wants to behave”. The combination of driving out the modern solution by discussing both “why” and “how” in the same process usually leads to a shared understanding of the direction the modernization should take. The information gained through this process can inform decisions on how to organize development teams, prioritize stories from both a business and technical perspective and generally, lay out a way to get from point A to point B.
The Swift Method activities include Event Storming, The Boris Exercise, SnapE, Thin Slice Definition and a backlog of work needed to get from legacy to modern.
True Modernization is not simply rewriting an existing system in a new technology, it’s about understanding the system and how it relates to the core enterprise as a whole.
The Swift Method consists of 5 tools and exercises. These tools each serve different purposes and represent layers of detail a team can use to drill down through a software system to determine how the system "wants to be designed". Other tools in this kit help understand how to incrementally get from the current state to the notional future state over time.
Discover Domains, Context Boundaries, Common Language
There are many flavors of event storming.
With the Swift Method, we use event storming to make sense of the mess, determine service candidates, bounded contexts and capabilities of a system by discovering clumps of business events.
These clumps or common groupings give us our notional service candidates (actors or aggregates depending on how rigid the team is with DDD definitions). These will be used during the Boris Exercise.
This process also enables cross perspective conversation throughout the team as well as a standard definition of the terms used by both technical and non-technical team members.
Discover APIs, Data, Synchronicity, Slices of Functionality. You know, the architecture.
Boris uses graph theory to model the relationships between the capabilities in a system. This process generates information about how the system "wants to be designed" and attempts to avoid pitfalls such as premature solutioning.
At the end of a Boris Exercise, Services, APIs, Data and Event Choreography and a backlog of work starts becoming obvious.
A good Boris Facilitator should be able to drive out how a system should be designed based on supporting the business capabilities from a DDD perspective. This notional architecture now represents a good first cut direction of the system. When used as a tool for modernizing existing systems, Boris reveals the likely target architecture. Other activities in the Swift Method help define how to get from Current State to Modernized.
Extreme Rapid Documentation
SNAP-E is a technique for quickly documenting the outcome from a Boris Exercise in real-time. Typically there will be one SNAP-E per node or service depicted on Boris. Each SNAP-E consists of documentation about five categories: APIs, Data, External Systems/UI, Stories and Risks.
Implementation Patterns
At this point in the Swift Methodology, we start defining the first patterns to use while building out the system we have defined. This would include Anti-corruption layers for monolith decomposition, asynchronous messaging, data storage (SQL/NoSQL), etc.
Creating an Agile Backlog
By going through the previous steps, a list of stories and tasks will be documented in the SNAP-Es. Creation of the backlog is a matter of prioritizing the stories based on the highest priority thin-slice of functionality. This step will also be used to formalize the stories by mapping them to any technical patterns that are defined.