Skip to main content

Architectural Guidelines

To elaborate on the above, as there are many design principles and many options on how to build software, it is good practice to use Ebbinghaus’s forgetting curve and benefit from repetition through the standardization of good architectural design guidelines. By this, we don’t mean architecture itself, just some good guidelines that don’t touch upon technology choice specifics.

For example, a guideline that would help is: “We prefer dumb pipelines and smart services over BPMN orchestration.” This way, when a choice is given, you don’t need to use a lot of effort to make a decision; it’s made for you already, lowering cognitive load.

Do consider the word “guideline"—it is not a rule that must be obeyed.

If there are sound reasons to deviate from the given guidelines, one can (with consent) decide not to comply and file an architectural decision record (ADR) to clarify the reasoning. If you notice there are more ADRs than compliance to the guidelines, then maybe the guidelines aren’t that great and need revisiting.

More on ADRs can be found here:

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html