Happy Birthday 'The Concerned Architect': Five Years, 50 Posts
(Updated: )Reading time: 4 minutes

Content Outline
I started this website and blog in the spring of 2020 (had a lot of time on my hands back then 😉). This “meta” post recapitulates some highlights from five years of blogging. Expect content on architecture decisions (ADs) and practices to manage and record them, patterns and principles for API design, a design “method melange”1 and more!
Architecture Decisions (ADs) and AD Records (ADRs)
Architectural Decisions (ADs) are a particularly popular topic. Two posts feature ADR templates:
- “The Markdown ADR (MADR) Template Explained and Distilled”. This post presents the MADR template elements one by one. The template is available from the MADR repository on GitHub (which has more than 1700 stars 🙏).
- “Architectural Decisions — The Making Of” develops the need for ADRs and provides evidence that architectural decision capturing is a concept that goes back to late 1990s. The post also features my Y-Statement template from ABB times:2
Several posts look into AD management process and supporting practices, including:
- “How to create Architectural Decision Records (ADRs) — and how not to”, featuring AD capturing patterns and anti-patterns (metaphors: journal, scale, action plan).
- “A Definition of Done for Architectural Decision Making” with five criteria: evidence, criteria, agreement, documentation and realization/review (ecADR, pronounced “easy ADR”).
- “A Definition of Ready for Architectural Decisions (ADs)” advises to START when ready. START is short for stakeholders, time, alternatives, requirements, template. The post also covers the Most Responsible Moment (MRM) for ADs, which varies by type.
Another post shares advice how to review (and how not to), and the blog has an #architectural decisions tag. My ITARC 2024 presentation “Timing Architectural Decisions” complements the blog content with newer material (not yet blogged about).
By the way, I am considering to turn my AD material into a Leanpub eBook, with extras such as
decision guidance (reusable AD catalog), application examples and road stories. Stay tuned!
API Design, Cloud Computing, Microservices
The posts on these topics were fun to write, leveraging experience gained on client engagements and writing projects:
- “New Book “Patterns for API Design” Published” was the first post to feature our 2022 book in the Vaughn Vernon Signature Series at Addison Wesley. 21 of its patterns were featured in “API Design Pattern of the Week”, an article series on LinkedIn and Medium (see this post).
- “API Design Review Checklist: Questions Concerning the Developer Experience (DX)” came to life in response to a question from Gregor Hohpe, author of “Cloud Strategy”, Enterprise Integration Patterns and related ramblings as well as the IT Architect Elevator.
-
“What is a Cloud-Native Application Anyway? From Analysis to Synthesis” suggests SUPER-IDEAL as a backronym for cloud usage characteristics and distills seven traits for cloud-native applications and migrations:
- Fit for purpose
- Rightsized and modular
- Sovereign and tolerant,
- Resilient and protected
- Controllable and adaptable
- Workload-aware and resource-efficient
- Agile and tool-supported.
These “Cloud Seven” are shown as as building blocks in this figure from the post:
There is more on API design and other tagged topics.
Software Engineering (with Method Melange)
A melange is a mixture or medley according to Wikipedia. I compiled and combined elements from existing methods, and blended them with members of my personal toolbox in the Design Practice Reference/Repository (DPR). Two posts feature DPR (with examples):
- DPR: an Open Source Repository Collecting Mighty Methods
- Design Practice Repository/Reference: GitPages and eBook Enhanced
DPR comes as a LeanPub eBook and as a public GitHub repository (with GitPages support). This figure gives an overview of the DPR content and how its activities and artifacts relate to each other, for instance SMART Non-Functional Requirements (NFRs) driving the architectural modeling:
Co-authors and contributors. I’d like to use the anniversary of the blog to acknowledge and thank my guest bloggers and contributing authors one more time:3
- Mirko Stocker and Stefan Kapferer contributed to several posts.
- Mirko is a co-author of the API design patterns, DPR and the posts “What is a Cloud-Native Application Anyway? 12 Definitions Distilled” and “What is a Cloud-Native Application Anyway? From Analysis to Synthesis”.
- Stefan and I reported on: “Domain-Driven Design in Practice — Experience with Context Mapper” (Part 1). The report continues here (external link).
- Hans-Peter Hoidn, my former colleague at IBM, contributed two posts:
- Joint work with Mohsen Anvaari, former PhD student at NTNU (visiting HSR/OST at the time), and now a consulting enterprise and software architect, led to a proposal of a maturity model4 for AD practices:
- “An Adoption Model for Architectural Decision Making and Capturing”.
The overview figure from that post is:
- “An Adoption Model for Architectural Decision Making and Capturing”.
Technical Writing, Research-to-Practice Advice
Practical relevance of software research is a topic near and dear to my heart. It has kept the community concerned for a long time, and will continue to do so for the foreseeable future.
The following posts discuss reasons for the research-practice gap and suggest how to overcome it:
- “Messages from Practice to Academia, Part 1: New Journal Column ‘Dear Researchers’”
- “Messages from Practice to Academia, Part 2: Reasons for the Research-Practice Gap”
- “Messages from Practice to Academia, Part 3: Bridge Building and Topics of Interest”
More general research, writing and review advice can be found in:
- “How to Write Review-Friendly Articles”
- “Shorthand and Markup for Speedy Note-Taking and Review Comments”
- “Research Methods and Peer Review Advice”
- “Do’s and Don’ts in Technical Reports about Term and Thesis Projects”:
The blog has an authoring, a patterns and a principles category (among others).
IT Entertainment
IT/computer science topics can be dry, so I like to spice discussions up a bit sometimes. Two semi-serious posts give an impression:
- “Driven by Acronyms (aka Cooking IT Alphabet Soup)” reviews “driven” and “oriented” methods from A to Z, and collects common TLAs (three letter acronyms, that is).
- The proposal for “Novel Measurements for Academic Work (and Beyond?)” got longer than expected (and more serious, in parts).
- How do you like the simplified “hype bucket model” on the page “Miscellaneous Advice and Story Snippets”? 😂
The post “Blog Index (and Pointers to other Blogs)” lists all posts in this blog, grouped and ordered by topics (the pointers to other blogs moved to a separate page recently).
Wrap Up
If you work in roles such as software architect, API designer and/or technical writer, you’ll hopefully find — or rediscover — something relevant and interesting (and/or at least entertaining) in the featured posts.
The Medium pendant of this blog has shortened versions of the posts on software architecture and ADRs as well as those on API design, cloud-nativity and microservices. The website supporting our “Patterns for API Design” book features pattern summaries, tutorials and pattern adoption stories.
Stay tuned… you may want to subscribe to the RSS feed for this site/blog!
– Olaf aka ZIO, socadk, DocSoC5
Editorial information: no AI was used to write this post (or any of the previous 49).
Notes
-
Alliterations almost always are applicable, aren’t they? 😊 ↩
-
The Y-Statement template is also known as decision stories, see the section “Trade-offs in design decisions” in “Architectural design with autonomous teams” by Eltjo Poort. ↩
-
As well as my pattern co-authors and reviewers of drafts, including Andrei, Cesare, Christian, Daniel, Eoin, Gerald, Hagen, Justus, Olly, Uwe. 🙏 Drop me an email if your name seems to be missing! ↩
-
We deliberately decided not to call it a maturity model. Read the post to find out why. ↩
-
These are my humble attempts to confuse crawlers and profile building tools. 😉 ↩