26 Fundamental Techniques for Software Architects

In the fast-paced world of software development, the right architecture can make or break the success of a software initiative.

As organisations grapple with ever-changing requirements, stakeholders, and cutting-edge technologies, mastering a variety of techniques is paramount.

Here's my latest overview: a list of the most important techniques for software architects.

This comprehensive collection gives architects the techniques they need to not only design solid architectures, but to seamlessly align them with business goals.

Learn how these techniques enable architects and teams to make informed decisions, minimise risk, and communicate effortlessly with stakeholders.

Let's dive in!

The list is not complete! If important techniques for software architects are missing, please let me know.

Strategic Planning & Strategic Decision Making

💡
Impact Mapping: a collaborative strategy tool that visually aligns an organisation's efforts with measurable goals to achieve effective impact and success.

Wardley Mapping: a visual strategic tool that aids in understanding business value chains and decision making by visualising the maturity and connectivity of components.

Impact Mapping

Impact mapping is a strategic planning technique that helps organizations identify and prioritize actions based on their potential impact on achieving a specific goal.

It involves all stakeholders working together to define the goals, the actors that can influence the outcomes, the impacts that contribute to the goal, and deliverables that these impacts can produce.

This visual roadmap aligns teams and resources around measurable outcomes and ensures that efforts are focused on activities that deliver real value and drive success.

Example of an Impact Map (Source)
Impact Mapping
Impact Mapping community web site
Impact Mapping: Our Impact as an agile organisation
We often talk a lot about various initiatives and the resulting technical solutions in detail. But we often do so without keeping in mind the specific business objective and the desired impact we want to achieve. This is where Impact Mapping comes in.

Wardley Mapping

Wardley Mapping is a strategic planning tool that helps companies to visualize the value chain of their products and services in order to better understand their competitive environment.

Developed by Simon Wardley, the mapping depicts the components of a business or service as a chain of needs and shows their level of maturity from commodity to customized products.

This visual approach helps companies to identify areas of inefficiency, predict industry trends and decide where to invest resources for innovation and improvement to make better strategic decisions.

Great talk by Markus Harrer about Wardley Mapping

The Book
This is the story of Simon Wardley’s journey, from a bumbling and confused CEO lost in the headlights of change to having a vague idea of what he was doing.
The Art of Strategy: Wardley Mapping Examples
Annex: A curated, diverse and updated atlas of valuable maps

Initial Concept, Aligning Teams & Structuring

💡
Domain Storytelling: Initiates the understanding of business processes and creates a narrative foundation for everyone involved.

Event Storming: a collaborative, visual modeling technique used by teams to explore complex business domains by identifying and discussing events, commands and policies.

Ubiquitous Language: a common vocabulary that ensures clear communication throughout the software lifecycle.

Architecture Inception Canvas: Captures the initial architecture playground, including business drivers and constraints.

Q42: is a simple and practical method for evaluating product and system quality.

Quality Storming: Collaborative modeling for a cross-skill collection and prioritization of quality requirements for software.

Event Modeling: is a visual technique to design and understand system architectures.

Context Mapping: identifies and describes the contact between bounded contexts and teams.

Bounded Context Canvas: helps architects to define the boundaries within which a particular domain model applies.

Domain Storytelling

Domain Story Telling is a narrative technique used to capture and communicate the business processes and requirements in a way that is easily understood by all stakeholders.

This approach helps to ensure that the software solution meets the business requirements.

Example Domain Story Telling (Source)
Domain Storytelling
A collaborative, visual, and agile way to build domain-driven software

Event Storming

Event Storming is a collaborative, visual modeling technique used by teams to explore complex business domains by identifying and discussing events, commands and policies.

Event Storming Talk by Alberto Brandolini at the DDD Europe 2019

Ubiquitous Language

Introduces a common vocabulary to ensure clear communication throughout the whole software lifecycle.

bliki: Ubiquitous Language
a bliki entry for Ubiquitous Language

Martin Fowler about the ubiquitous language

Ubiquitous Language simplified

Architecture Inception Canvas

The journey begins with the Architecture Inception Canvas (formerly Software Architecture Canvas), a technique for capturing the essence of a software initiative, business drivers, constraints, business context and initial architecture assumptions.

Software Architecture Canvas: A Collaborative Way to Your Software Architecture
The Software Architecture Canvas is a collaborative technique for elaborating the software architecture playground of a software initiative. With this canvas, you can work efficiently, iteratively, and in a time-saving manner on the software architecture of your software products as a team sport.
Architecture Inception Canvas (Source)
Architecture Inception Canvas
An Efficient and Collaborative Way to Define your Software Architecture Playground

Frontend Architecture Map

The Frontend Architecture Map is a user-centered approach that focuses on aligning frontend development with actual user needs rather than trends. The focus is on understanding user interactions and designing an architecture that effectively supports these journeys. The map helps teams to identify the most appropriate technologies and practices while avoiding hype-driven decisions. Their goal is to create a more suitable and user-centered front-end architecture.

The Frontend Architecture Map
Frontend Architecture Map Template | Miroverse
Discover how Patrick Roos does Frontend Architecture Map in Miro with Miroverse, the Miro Community Templates Gallery. View Patrick Roos’s Miro templates.
GitHub - bitsmuggler/frontend-architecture-map: A User Journey-Driven Architecture Technique for Optimal Frontend Technology Selection
A User Journey-Driven Architecture Technique for Optimal Frontend Technology Selection - bitsmuggler/frontend-architecture-map

arc42 Quality Model

As ISO 25010 lacks practical guidance and pragmatism, there is an alternative approach proposed by arc42 - the arc42 quality model "Q42".

The arc42 Quality Model "Q42" is a straightforward and practical method for assessing product and system quality.

arc42 Quality Model (Image Source)

It starts with understanding stakeholder expectations and requirements to identify 8 key system properties.

These properties are designed to encompass most of the 100+ traditional quality attributes that are required, desired or expected.

Home
quality attributes, explained.
A Guide to Non-Functional Requirements for Software Architects
Discover modern techniques and tools to effectively elicit, document and improve the management of the quality requirements of a software initiative.

Quality storming

Quality Storming is a workshop for determining quality requirements based on a quality model such as the ISO 25010 standard. This method uses techniques and ideas from Collaborative Modeling, which is very popular in the Domain-Driven Design community. An important aspect of Quality Storming is the collaboration between different stakeholders and departments.

QualityStorming: Collaborative Modelling for Quality Requirements

Event modeling

Event modeling is a visual technique for designing and understanding system architectures through the representation of events, commands, and views that show how data flows and changes in a system. Perfect for aligning teams around complex processes.

Adam Dymitruk. Event Modeling from Beginner to Expert

Event Modeling Example (Source)
Event Modeling: What is it?
Event Modeling is a way to design a blueprint for an Information System of any size or scale. It is done in a way that allows the clearest communication of the system’s workings to the largest possible cross-section of roles in an organization. The system can be checked for completeness by following the single thread of data propagation through it.

Context Mapping

Context maps are visual or conceptual diagrams that illustrate how different bounded contexts (different functional areas within a software system) interact with each other.

They help to understand the relationships and dependencies between these contexts, such as shared identities, customer/supplier relationships or different types of system integration.

Context maps are crucial for maintaining a clear architecture and facilitate communication between teams working on different parts of a system.

Introduction to Context Mapping by Michael Plöd

Context Mapping Example (Source)

Bounded Context Canvas

The Bounded Context Canvas helps architects to define the boundaries within which a particular domain model applies. This is important to manage complexity and ensure that the different components of the system communicate effectively with each other.

Bounded Context Canvas (Source)
GitHub - ddd-crew/bounded-context-canvas: A structured approach to designing and documenting each of your bounded contexts
A structured approach to designing and documenting each of your bounded contexts - ddd-crew/bounded-context-canvas

Domain Prototyping

Domain prototyping is a technique in which a preliminary version of a system or software module is created to explore and validate concepts within a particular domain.

This approach helps developers and stakeholders understand system requirements, functionalities and potential issues by giving them a hands-on preview before full-scale development begins.

It is particularly useful for complex systems where domain knowledge is highly intricate, as it allows for iterative feedback and refinements that ensure the final product is better aligned with user needs and expectations.

Tobias Goeschel about Domain Prototyping

Decision Making

💡
Architecture Principles: guide decision-making by providing a set of values and standards that align the software initiative with organisational goals and best practises.

Architecture Decision Records: ensure that decisions are made transparently and systematically and can be revised as the software evolves.

Architecture Principles

The architectural principles guide decision-making by providing a set of values and standards that align the project with organisational goals and best practises.

Architecture Principles: An approach to effective decision making in software architecture
Are you a software architect and often find it difficult to make architecture decisions in your team? This article shows you how to use architecture principles to make effective decisions in your team.

Architecture Decision Records

The decision-making process in the architecture, which can be documented by Architecture Decision Records (ADR), ensures that decisions are made transparently and systematically and can be reviewed during the life cycle of the software.

Technology Management

💡
Tech Stack Canvas: Create, document and communicate the product's tech stack.

Technology Radar: A technique used by companies to map their current technology landscape and identify new technologies on which they should focus.

Tech Stack Canvas

The Tech Stack Canvas is a technique used by software development teams to map, document, visualize and communicate the technologies and tools used in a software product.

Tech Stack Canvas (Source)

Technology Radar

A technology radar is a technique that companies can use to map their current technology landscape and identify new technologies they should focus on.

It visualizes technologies in four categories: Adopt, Try, Assess and Hold. This helps stakeholders understand which technologies are recommended for adoption, which need further research and which should be avoided.

This technique helps in strategic decision making regarding technology investment and adoption and ensures that it aligns with business goals and industry trends.

Technology Radar by Thoughtworks (Source)
Inspirational Technology Radar Examples
In this article you will find inspiring examples of different companies documenting their technology management with a technology radar and making the results public.

Visualisation & Documentation

💡
Architecture Communication Canvas: helps to communicate key elements of existing software architectures.

C4 Model: is a technique for visualizing software architecture.

arc42 template: is a technique for documenting software architectures.

Documentation as Code: is a technique in which documentation is treated like software code
The Ultimate Guide To Software Architecture Documentation
This guide shows you how to write, structure, visualize and manage software architecture documentation in a lean way using appropriate documentation tools.

Architecture Communication Canvas

The Architecture Communication Canvas helps to communicate key elements of existing software architectures.

The Architecture Communication Canvas (Source)
Architecture Communication Canvas
The shortest possible description of your architecture

C4 Model

The C4 Model is a technique for visualizing software architectures that offers different perspectives (Context, Containers, Components and Code) to meet the different needs of stakeholders.

The C4 model for visualising software architecture (Source)

arc42 Template

The arc42 template is a technique for structuring software architecture documentation.

It provides a systematic structure for capturing and organizing important information about software architecture, including their context, structure, and architectural decisions.

The template is divided into 12 sections that help developers describe the architecture and improve communication and understanding between stakeholders.

The arc42 template structure (Source)
arc42 Template Overview
arc42 is a template for architecture communication and documentation.

Documentation as Code

Documentation as code is a technique in which documentation is treated like software code, i.e. it is written in plain text, version controlled and stored together with the software it describes.

This technique uses tools that are common in software development, e.g. Git for version control and continuous integration systems for automatic testing and the provision of documentation updates.

By integrating documentation into the development process, teams can maintain more accurate and up-to-date documentation that evolves with the software and improves accessibility and collaboration.

Documentation as Code with Visual Studio Code
What is Documentation as Code? And why do you need it?
“Documentation as Code” means that your documentation process benefits from the same techniques used in software development.

Assess, Measure, Improve and Adapt

💡
Risk Storming: is a collaborative technique for identifying potential risks and developing mitigation strategies

DORA Metrics: provide quantitative measures of software delivery performance that provide insight into the effectiveness of the development process and areas for improvement.

LASR: is a streamlined and goal-oriented method for evaluating software architectures

aim42: is a systematic approach to improving the quality and maintainability of software systems.

Risk Storming

Risk-storming is a collaborative technique for identifying potential risks and developing mitigation strategies to ensure that the project is resilient in the face of uncertainties.

Risk-storming - a visual and collaboartive risk identification technique (Source)
Risk-storming

DORA Metrics

DORA Metrics provide quantitative measures of software delivery performance that provide insight into the effectiveness of the development process and areas for improvement.

Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog
Learn how the Four Keys open source project lets you gauge your DevOps performance according to DORA metrics.

Lightweight Approach for Software Architecture Reviews

Lightweight Approach for Software Architecture Reviews (LASR) is a streamlined and goal-oriented technique for evaluating software architectures and offers a leaner alternative to traditional methods such as ATAM (Architecture Tradeoff Analysis Method).

It can be performed quickly, even within a single afternoon, by a team or individually, making it highly adaptable and efficient.

LASR - Lightweight Approach for Software Reviews - embarc
LASR (Lightweight Approach for Software Reviews) ist ein strukturiertes Vorgehen für leichtgewichtige Software-Reviews.

The following cheat sheet describes LASR beautifully illustrated on 4 pages (English, PDF) 👇

Spicker #12: Leichtgewichtige Software-Reviews mit LASR - embarc
Reviews decken Schwächen von Softwarelösungen auf und sichern technische und architektonische Ideen ab. Dieser Spicker beschreibt einen skalierbaren Bewertungsansatz, der rasch Ergebnisse liefert.

aim42 - Architecture Improvement Method

aim42 is a systematic approach to improving the quality and maintainability of software systems. It is a structured method for evaluating software architecture, identifying problems and implementing improvements based on practical and best practices.

This method is collaborative, adaptable to different types of software projects and helps organizations improve the performance, scalability and overall health of their software architecture.

Architecture Improvement Method
systematic software evolution

Residuality Theory

Residuality theory is a new, revolutionary concept that proposes an ideology for the development of software systems that is concerned not only with the intended purpose of the software, but also with anticipating and solving future problems. According to Barry M. O’Reilly, the author of Residuality Theory, software systems should not be complex and static, but should be able to change under stress. If we view systems as a series of residues associated with stressors, we can better understand how design decisions affect the lifecycle of software systems and their unpredictable complexity.

Residues: Time, Change, and Uncertainty in Software Architecture.
An introduction to Residuality Theory, fusing Software Engineering and Complexity Science to produce new methods for designing software.