The Concerned Architect (ZIO’s Blog)
Why is this blog called “The Concerned Architect”? Software architects1 (hopefully) address functional and non-functional stakeholder concerns.2
Architects may apply patterns. And some of them get engaged in research and tool development projects. Hence, the posts in this blog take three different views on software architecture: practicing architect (ZIO), pattern enthusiast (MAP Author), and software engineering researcher and tool smith (socadk).
All posts are listed in an index post. The tags page provides a keyword-based directory. There is an RSS feed for this blog. Terms and conditions apply.3
New and Noteworthy
Article Series 'API Design Pattern of the Week'
The authors of the Addison-Wesley book “Patterns for API Design — Simplifying Integration with Loosely Coupled Message Exchanges” publish(ed) 21 articles online last year, featuring...
A Definition of Ready for Architectural Decisions (ADs)
It is important to hit the most responsible moment for an Architectural Decision (AD) about a pattern or other concept, technology or product. But when...
An Adoption Model for Architectural Decision Making and Capturing
Architectural Decision (AD) making and capturing are essential tasks for enterprise architects and solution architects; Architectural Decision Records (ADRs) have become increasingly popular. However, principles...
How to create Architectural Decision Records (ADRs) — and how not to
ADR stands for architectural decision record, but could just as well stand for archive of design rationale. This post is about making ADRs valuable; a...
Design Practice Repository and Reference: GitPages Enhanced and eBook Completed
Our public Design Practice Repository (DPR) and the corresponding eBook at LeanPub collect proven method elements for agile architecting in general and API/service design in...
The Markdown ADR (MADR) Template Explained and Distilled
The Markdown Architectural Decision Record (MADR) Template turned five on Nov 22, 2022. MADR stems from documenting architectural decisions and used to be named “Markdown...
Timeline (All Posts by Publication Date)
Article Series 'API Design Pattern of the Week'
The authors of the Addison-Wesley book “Patterns for API Design — Simplifying Integration with Loosely Coupled Message Exchanges” publish(ed) 21 articles online last year, featuring selected patterns from their book....
A Definition of Ready for Architectural Decisions (ADs)
It is important to hit the most responsible moment for an Architectural Decision (AD) about a pattern or other concept, technology or product. But when is an AD actually ready...
Returning to EuroPLoP — Topics: API Refactoring and Pattern Visualization
EuroPLoP is one of the go-to conferences on all things patterns; our “Patterns for API Design” benefitted a lot from EuroPLoP writers’ workshops 2017 to 2020. All five co-authors of...
Notes from The Architecture and Modeling Learning Event — Vaughn Vernon Signature Series Live in Action
The authors of Vaughn’s book series at Addison Wesley teamed up for a free online conference. “The Architecture and Modeling Learning Event” covered not only software architecture, domain modeling and...
How to Build and Run a Decision-Making Architecture Board
This guest post is about collaborative architectural decision making, by way of a cross-organization software architecture board. My former colleague Hans-Peter Hoidn reports on motivation, setup and value of such...
An Adoption Model for Architectural Decision Making and Capturing
Architectural Decision (AD) making and capturing are essential tasks for enterprise architects and solution architects; Architectural Decision Records (ADRs) have become increasingly popular. However, principles and practices for AD management...
How to review Architectural Decision Records (ADRs) — and how not to
This post reflects about reviewing ADRs. It identifies three review perspectives, recommends related practices and discusses anti-patterns. A review checklist is provided and an ADR reviewer pledge proposed.1 ADR stands...
How to create Architectural Decision Records (ADRs) — and how not to
ADR stands for architectural decision record, but could just as well stand for archive of design rationale. This post is about making ADRs valuable; a sibling post covers ADR review....
API Design Review Checklist: Questions Concerning the Developer Experience (DX)
This post lists 25 questions to ask when reviewing the Developer Experience (DX) of an API. It groups them by the four DX pillars (functionality, stability, ease of use, clarity)...
Design Practice Repository and Reference: GitPages Enhanced and eBook Completed
Our public Design Practice Repository (DPR) and the corresponding eBook at LeanPub collect proven method elements for agile architecting in general and API/service design in particular. Version 1.5 of the...
API Patterns Website Redesigned and Sample Book Chapter Available
Update (November 9, 2023): 19 of our API design patterns are also featured in online articles now. A story on Medium list them.
Domain-Driven Design in Practice — Experience with Context Mapper
Context Mapper is an open source DSL and tool for Domain-driven design (DDD), resulting from joint work by Stefan Kapferer and Olaf Zimmermann. This post and a sibling give a...
The Markdown ADR (MADR) Template Explained and Distilled
The Markdown Architectural Decision Record (MADR) Template turned five on Nov 22, 2022. MADR stems from documenting architectural decisions and used to be named “Markdown Architectural Decision Records”; but time...
Questions to Ask when Migrating to the Cloud
Cloud-Native Application (CNA) has been a trending buzzword in blogs, books and articles for several years now. But what about migrating an application to the cloud? How to find out...
New Book 'Patterns for API Design' Published
Our pattern language for API and service design forms the core of a Signature Series book published by Addison Wesley Professional!
Process-Oriented Service Design with Discrete Event Simulation
The post on “Event-Driven Service Design” proposes continuous refinement steps to derive process flows and API designs from event-command chains. Here, we show how to convert such process flows to...
Story-Driven Service Design: From Feature Request to Minimum Viable API Product
Goal-oriented API design (“contract-first”) is a recommended practice in the Web API community; data modeling is equally important to balance API granularity and client-provider coupling. Finally, refactoring to API patterns...
Event-Driven Service Design: Five Steps from Event Storming to OpenAPI and Camel Flow
Event storming workshops yield domain events and commands (among other artifacts). This post proposes a continuous refinement process to derive an API design and an executable integration flow from such...
What is a Cloud-Native Application Anyway? From Analysis to Synthesis
In a previous post, we collected twelve definitions of cloud-native. In this post, we derive yet another one from those (and our own experience). Two, actually (“How standards proliferate”).
What is a Cloud-Native Application Anyway? 12 Definitions Distilled
Cloud-Native Application (CNA) has been a trending buzzword in blogs, books and articles for several years now. But what does it take for an application to be(come) cloud-native? Do we...
ADR = Any Decision Record? Architecture, Design and Beyond
If architectural decision records are so useful to capture software design rationale, why not extend their scope: Can they log organizational and managerial decisions as well? How about everyday decisions?...
Survey on API Change Drivers and Evolution (Finished)
It would be great if you could help the community to find out what future API design methods and tools should do – by filling out a short survey.
APIs should get to the POINT
This post proposes five principles for API design, summarized in the backronym POINT: purposeful, style-oriented, isolated, channel-neutral and T-shaped.
Research Methods and Peer Review Advice
Which level of research rigor and result maturity is required to satisfy paper reviewers? I shared tips how to write for reviewability and how to review before. Here are some...
Awesome Architecture Descriptions and Pattern Languages
This “meta-post” points you at valuable templates for documenting software architectures as well as a few pattern languages that can support their creation.
Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?
Should our favorite “-ilities” and miscellaneous design/decision drivers be filed under “Non-Functional Requirements” or “Extra-Functional Requirements”? The two editors of IEEE Software Insights do not agree. Read their arguments and...
Driven by Acronyms
Aspect-oriented programming, behavior-driven development, CAP theorem… can we cook some more IT alphabet soup? This method and practice reference (as is, to be) and TLA resolver is not to be...
DPR: Open Source Repository and eBook Collecting Mighty Methods
The Design Practice Repository (DPR) on GitHub collects proven method elements and other knowledge nuggets for API and service design — and agile software architecture work in general. This post...
Architectural Significance Criteria and Some Core Decisions Required
What is important when analyzing and designing software architectures, and what is not? This post proposes 5+2 criteria for the architectural significance of requirements (and other artifacts) and applies them...
Microservices Positions and Consolidated Definition
Microservice architectures evolved from previous incarnations of Service-Oriented Architectures (SOAs) to promote agility and elasticity. This post updates the SOA vs. microservices positioning part of an older IFS web page...
Shorthand and Markup for Speedy Note-Taking
I review documents a lot, and I attend many meetings too. Creating meeting minutes or review comments ain’t fun; the same holds for processing them. Over the years, I have...
Wanted: Your Insights, Stories and Experience Reports
Do you have real-world software engineering experience to share? Maybe you have presented on it already, or blogged about it? And you would like to “upgrade” to an official publication...
Domain-Driven Service Design with Context Mapper and MDSL
In an ICWE keynote, I presented(ed) our evolving tool chain for object-oriented analysis and design (or DDD, to be precise) and service design. Here’s how to run the full demo....
How to Write Review-Friendly Articles
Scientific and technical writing is hard and requires deliberate practice. I already blogged about some of the challenges. Here is some more advice.
A Definition of Done for Architectural Decision Making
It is good to know when the most responsible moment for an architectural decision about a pattern or technology has come. But when can a decision be considered done? This...
Getting Started with Microservice API Patterns (MAP)
In a previous post, I reflected about the evolution of Microservice API Patterns (MAP) since 2016. This “meta-post” points you at presentations and articles motivating the need for MAP, introducing...
Conference Updates: ECSA, ICSA, SummerSoC, EuroPLoP 202x
Difficult times for conference organizers… ECSA 2020 and Microservices 2020, two events I helped organize in 2020, took place online. What is happening in 2021?
MAP Retrospective and Outlook
Microservices are still trending, but not straightforward to design well. Patterns are a mature and elaborate form of knowledge sharing, so Microservice API Patterns (MAP) complement other pattern languages to...
Architectural Decisions — The Making Of
Architectural Decisions (ADs) have been answering “why” questions about design options since the inception of software architecture in the 1990s. Ways to capture them should be part of each architect’s...
Technical Writing Tips and Tricks
When authoring specifications, technical documentation or articles, many pitfalls wait for authors (and, as a consequence, their readers) — but there are ways around them. In this post, I’ll highlight...
Blog Index and Pointers to other Blogs
This “meta-post” indexes all posts in The Concerned Architect (by topic) and points to blogs that I visit when I am not busy consulting, designing, coding, teaching, writing.
-
Not necessarily a person; agile teams tend to share the architectural responsibilities, so were are talking about a virtual, distributed role when we say “architect”. Not convinced? Read “The Software Architect’s Role in the Digital Age”. ↩
-
And yes, I get a bit concerned about certain issues sometimes… which ones? Future posts will elaborate. ↩
-
See page Terms and Conditions. ↩