As responsible software engineers, we do not like to be bossed around. Decentralized decision making and autonomous teams might not be listed explicitly as values in the Agile Manifesto, but are certainly valued and practiced a lot in agile teams and organizations.
Agile does equal anarchy; agile teams actually are quite (self-)disciplined and employ a number of ceremonies (a.k.a. practices). Most of them are collected and commented upon elsewhere, for instance try the Subway Map to Agile Practices and glossary by the Agile Alliance. Here in DPR, we focus on agile architecting and service/API design and collect some of the method elements, tactics, practices, etc. that served us well or that are frequently recommended, for instance in microservices books. These activities consume and produce the artifacts listed in a sibling folder, possibly supported by checklists and templates; they are owned and performed by one or more of the personas and roles also documented in this repository.
One should never forget the first rule of method adoption:
If in doubt, leave it out (or: do not create a big ball of method mud).
Other general hints for all design and modeling activities are:
- Always write for a particular target audience (stakeholders with concerns) and model purposefully.
- Follow a "good enough" approach to decision making and documentation.
- Apply patterns and other reusable assets to reduce risk and cut cost.
Particularly relevant for service/API design are:
- Strategic DDD a.k.a. context mapping
- Tactic DDD models, Event Storming results, and those from other analysis practices
- Featured: Stepwise/Incremental Service Design (contract-first)
- User Interface Mocking (for APIs providing Frontend Integration capabilities)
- Integration Story Telling (for Backend Integration) (to be continued)
- Analysis of Architecturally Significant Requirements (ASRs), both functional and quality-oriented. Activities may include:
- Relevance assessment and prioritization, which can be supported by a checklist of ASR criteria (see blog post "Architectural Significance Test" for the time being)
- User Story-Based Iteration Planning, Story Mapping and Story Splitting
- Use Case Modeling (full vs. brief)
- SMART Non-Functional Requirement (NFR) Elicitation, including value-, risk-, and cost-based prioritization of NFRs, proposed in an article by Martin Glinz (PDF); very much in line with George Fairbank's advice on Just Enough Software Architecture. Quality storming has been proposed by Michael Ploed more recently.
- Specification of Agile landing zones (Rebecca Wirfs-Brock)
- Architecture Modeling
- "Architecture Overviewing" and Strategic Architecting
- Quality- and Pattern-Oriented Design
- Attribute-Driven Design (ADD) 3.0
- Pattern-Oriented Software Architecture (POSA) book series, Volume 4 in particular @Buschmann:2007
- Component Identification and Modeling
- Responsibility-Driven Design introduces role stereotypes and made CRC cards popular.
- "UML Components" by John Cheesman and John Daniels suggests steps to advance from use cases to components @CheesmanDaniels:2000
- Architectural Decision Capturing
- Yielding Y-statements, (M)ADRs or other forms of ADRs as artifacts
- Most Responsible Moment (MRM) scoring for ADs (dynamic?)
- Domain-Driven Design (DDD)
- Context Mapping in Strategic DDD
- Tactic DDD
- User Interface (UI) Design
- Coding the Architecture
- Operational Modeling
- As proposed by the IBM Global Services Method (see here)
Both lean/light and full-fledged techniques have been proposed:
- Tiny Architectural Review Approach (TARA)
- Decision-Centric Architecture Reviews (DCAR)
- Architetcure Tradeoff Analysis Method (ATAM)
- Architectural Roadmapping, described by Eltjo Poort in an IEEE Software Insights installment
- Risk-driven prioritization, introduced in George Fairbank's "Just Enough Software Architecture" (@Fairbanks:2010)
- Thomas Ronzon's Software Retrofit
Stefan Murer's book on "Managed Evolution" lists many more, and the Evolution category in MAP collects patterns for API versioning and life cycle management.
A number of frameworks and approaches for scaling agile exist, including:
Gregor Hohpe's IT/Software Architect Elevator always is worth a ride to the upper levels (and back).
Many of the activities (techniques and practices, that is) collected in this repository are partially or fully supported by tools; these tools then help produce the output artifacts.
Some of the ones we have contributed to, or work on, are:
- Context Mapper for domain modeling
- Editor and Linter for Microservice API Description Language (MDSL) for service contract design
- Architectural decision capturing and modeling: MADR, e-ADR, ADMentor
More specific information, also about other tools, can be found on the individual pages.
title: "Design Practice Repository (DPR): Activities (Practices, Techniques) Overview"
author: Olaf Zimmermann (ZIO)
date: "03, 17, 2021"
copyright: Olaf Zimmermann, 2020-2024 (unless noted otherwise). All rights reserved.
This work is licensed under a Creative Commons Attribution 4.0 International License.