Damn, this is really excellent. Over the course of my career I've written many tech specs, plans, one pagers, six pagers, functional requirements docs, ... etc. Each has been missing something, been too verbose, had sections that really don't integrate well. It's nice to see something a little more cohesive and rationalized.
Even if I don't ever use Arc42 explicitly in the future, this is a great reference of what things to remember and include in whatever other format of initial spec. Thanks for the overview.
Many of my documents do indeed have a similar layout for design and it is nice to see efforts like this to create more rigor in SW architecture. As a practitioner (and being opinionated), I have these observations:
- The "Building block view" is really the high level Structural Design. I tend to use structural decomposition to relay this information, iteratively breaking down into subsystems, components, etc. For this reason I prefer the term Structural.
- The "Runtime view" is really the Behavioral Design of the system, the sum of behaviors of a system is what you see at runtime.
I wonder if the terminology chosen for arc42 comes from a more academic or earlier time in SW architecture and design.
I'm also a fan of the C4 Model[1] for visualization. So I think I'm going to try to incorporate the two together, like, utilize arc42 for a formal and disciplined approach to architecture documentation coupled with the informative visual paradigm of C4 Landscape, Context, Containers, and Components.
As I was reading this I felt that it overlapped and complemented the C4 approach in a lot of places. There's even a superficial connection: C4 is contained in the title!
Agreed, the one thing I really think Simon [1] got right about visuals is the information they relay. Seeing a box diagram is one thing, e.g. boxes, arrows, names of tech (omg, @see AWS diagrams - they're really unexpressive deployment diagrams).
Compare that to a C4 Landscape or Context diagram - and its just night and day - so much more meaningful information and the ability to express not just structure, but to provide hints at data flows, actors, and externalities. In the end, I've found the most value for C4 in communicating architecture to upper management and new hires. These diagrams really make more sense than boxes and lines.
For arc42 I find the document content really appealing - its like engineering thinking. There is no standard template/model for design docs, perhaps this could start a baseline or trend to do something similar. I do still prefer Structural and Behavioral classifications.
i remember listening to a German-language podcast with the arc42 authors and they did mention volere. I forgot about the mutual history, but I think there was some resonance.
Can confirm that it's a great framework. We use it in all our Team and just having the same structure is a great start. It's a bit tedious the find the right place for the information in the beginning, but overall we are were happy with it
They also mention ADR (architecture decision records). Even if it’s yet another fad, most companies I’ve worked for really needed a framework like this.
I have only skimmed it so far but I’ll definitely talk to the managers and architects at my company about it. Any kind of formalization on this topic is greatly needed.
SysML (like UML) is a diagramming/modeling notation. Neither of them proposes any high-level structure for documentation.
arc42 proposes ONLY a high-level documentation/communicatin structure, and is notation agnostic: I've often used it with UML, and with informal box-and-lines diagrams.
The footnotes in this are messed up. The first one, when clicked the first time, landed in the middle of the article text, instead of at the footnote anchor. It looks like there's some misguided JS value-add lib in use here, which is meant to produce some smooth scrolling effect, but ends up making it worse...
The reference to the second is mangled and appears in the text as "[docs^]".
I would say arc42 is quite recognized documentation framework among software architects in Germany. My team is working with one major German automotive group and we/they are using slightly modified arc42 to document architectural parts + requirements for one of their core sw platforms.
Also as far as I’m aware arc42 is a part of training courses for iSAQ certification for sw architects.
arc42 is NOT part of the iSAQB Foundation curriculum.
Depending on trainers, it might be covered within iSAQB trainings.
If you are interested, you should check with your preferred training organisation in advance.
I was prepared to be upset that this article is an almost word-for-word copy of the "overview" page on the arc42 website (https://arc42.org/overview). But then I saw that the author is one of the arc42 maintainers. Now I need to find another target for my righteous indignation.
In short: You need text + diagramming tools. Go as light as possible, start small (draw.io and Markdown/AsciiDoc). Use high-end modeling tools (like Enterprise Architect or ArchiMate only in larger teams and/or with formal documentation requirements (20+ devs). Have a look at docToolchain.
I'm using yEd, but that likely has the same issues as you mention, being very open-ended and requiring lots of micromanagement of styles and layouts. Perhaps you are seeking a tool such as plantuml in which you specify your diagrams textually and have them rendered by a compiler. It only supports a specific set of diagram types, primarily from the UML family, but I think it's also possible to install a third party C4 style.
I'm confused, how is this different than a markdown file or google doc? Is the advantage that it has pre-specified headings with suggestions for the content?
As the author of arc42 writes in the article, the order of the chapters does not imply the order in which they should be decided upon and written.
In addition he writes that you might have already documented the most important decisions as part of the solution strategy chapter.
Most importantly, pick and choose based on your own judgement and experience those parts that you need and make it your own - in my experience arc42 has always been a good starting point when starting fresh or as a reference when evaluating existing documentation.
Even if I don't ever use Arc42 explicitly in the future, this is a great reference of what things to remember and include in whatever other format of initial spec. Thanks for the overview.