top of page
Concept of new ideas and innovation.jpg

SWIFTBIRD

Home of the Swift Method of Software Modernization

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

For System Design and Modernization

Event Storm

EVENT STORMING

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.

BORIS EXERCISE

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.

Boris
Snap-e

SNAP-E

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.

TECHNICAL 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.

Patterns
Communication Tower

STORIES AND 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.

bottom of page