readme.md

DPR: Activities in Service Design and Agile Architecting

Context and Motivation

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.

Activities Specific to Service/API Design

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)

Activities General Software Engineering/Architecture:

Architectural Analysis

• 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)

Architectural Synthesis

• 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
  • User Interface Mocking
• Coding the Architecture
  • Architecturally Evident Coding Styles
• Operational Modeling
  • As proposed by the IBM Global Services Method (see here)

Architectural Evaluation/Assessments

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 Evolution

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

IT Strategy and Enterprise/Program Architecture Work

A number of frameworks and approaches for scaling agile exist, including:

• SAFe
• Large-scale Scrum (LeSS)
• Disciplined Agile Delivery

Gregor Hohpe's IT/Software Architect Elevator always is worth a ride to the upper levels (and back).

Tool Support

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.

More Information

• See top-level readme.
• See background information folder.

DPR Metadata

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.

License

This work is licensed under a Creative Commons Attribution 4.0 International License.