24 Fundamental Techniques for Software Architects
Discover essential techniques for software architects to design modern systems, align with business goals, and manage stakeholders effectively. Learn more in this post!
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!
- Strategic Planning & Strategic Decision Making
- Initial Concept, Aligning Teams & Structuring
- Decision Making
- Technology Management
- Visualisation & Documentation
- Assess, Measure, Improve and Adapt
Strategic Planning & Strategic Decision Making
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.
Patrick Roos
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
Erik Schön
Initial Concept, Aligning Teams & Structuring
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.
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.
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.
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.
Patrick Roos
Gernot Starke, Patrick Roos and arc42 contributors.
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.
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.
Patrick Roos
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
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
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.
ddd-crewDomain 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 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.
Patrick Roos
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.
- ADRs: https://adr.github.io/
- Markdown Any Decision Records: https://adr.github.io/madr/
Technology Management
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.
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.
Patrick Roos
Visualisation & Documentation
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
Patrick Roos
Architecture Communication Canvas
The Architecture Communication Canvas helps to communicate key elements of existing software architectures.
Gernot Starke, Patrick Roos and arc42 contributors.
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.
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.
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.
Patrick RoosAssess, Measure, Improve and Adapt
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.
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.
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.
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.
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.
Barry M O’Reilly
Comments ()