A Simple Framework for Architectural Decisions | Hacker News Reader

A Simple Framework for Architectural Decisions

infoq.com

113 pointsmydevlprplanet12 comments

Architecture Decision Records can help teamwork. I teach tech teams about these, and maintain a repo of templates and examples:

https://github.com/joelparkerhenderson/architecture-decision...

Thanks for the link

Great resource. Do you teach teams virtually?

Naturally ADRs are only as good as they are made. That includes the process of coming to a decision and the effort put in writing them precisely and understandably. One can find many templates for them online and then pseudo-fill them, gaining almost zero benefit. Sometimes they are used to merely record premade decisions, which makes them OK for lookup, but adds nothing to the decision making process and is quite obvious when you read them.

The main use of an ADR isn't to arrive at a decision, but to record the choice that was made and why. Filling out an ADR and gaining zero benefit while doing it seems plausible - the hard work of arriving at a certain artefact is already done (hard work isn't a requirement).

In my solely own opinion:

an ADR documents a strategic choice and ties accountability to it's author. The quality of the document (and the content) should work in their own best interest.

Another kind of documentation could be used to record e.g. details of implementation or describing APIs. The latter is focused on building a knowledge base for co-workers, onboarding or end users. edit: I call them REFs.

edit 2: Filling out superfluous forms which ends up of no use to anyone is a waste of time. Cut back on documentation until people starts asking for more of it.

The enterprise architecture group at my employer seems to do nothing but introduce unnecessary bureaucracy and mandate tech choices with no input from those who have to use it.

Enterprise architecture is a form of quiet quitting. Just print out the Bash or Yaml files or whatever you used to configure your system and show it to your team: see guys it is just users, groups, files, processes, network interfaces, ports, ip addresses, dns records and the like.

> An internal Technology Radar can help teams understand the technology landscape and make informed decisions about which technologies to use.

A Technology Radar is supposed to reflect the state of your area and track what you are doing, like a radar. It's not a decision making tool; building a decision making process around it will eventually lead to rigid blocks and stifle your own innovation.

Something that provides information (like a radar) helps make informed decisions, not makes and suggests the decisions for you (like our upcoming AI overlords, or whatnot).

The decision us still up to you, the reader.

I've love each new release of the Thoughtworks radar. It's a great way to discover emerging tech by respected technologists.

Discovering their BYOR feature immediately triggered an idea around understanding your familiarity with prospective tech. E.g., if the tech is in an outer ring, you probably don't want to rush it into production.

https://www.thoughtworks.com/radar/byor

So much extra fluff and process. Why not just document your code. Use markdown files. And focus on working core?

In my experience good engineers get together in a room make decision swiftly and deploy them. Often with docs. Also worked with an RFC process which worked but also introduces a “checkpoint” which slows down decision making. Only for one door decisions such docs or joint decisions are needed.

All useful but keep it lean folks.

Architecture is not about technology. It’s about how to structure a system to best aid a given organization to achieve its strategic goals.

Reply on news.ycombinator.com