From 3a1b612c4e5bb5643f9a24bdf84a3f159f7271c1 Mon Sep 17 00:00:00 2001 From: Marc Gorzala Date: Sat, 11 Nov 2023 10:15:53 +0100 Subject: [PATCH] integrated tech decision principles --- .../architecture-decision-principles.adoc | 70 ++++++++----------- 1 file changed, 31 insertions(+), 39 deletions(-) diff --git a/src/main/jbake/content/architecture-decision-principles.adoc b/src/main/jbake/content/architecture-decision-principles.adoc index a3406df..a9c2c38 100644 --- a/src/main/jbake/content/architecture-decision-principles.adoc +++ b/src/main/jbake/content/architecture-decision-principles.adoc @@ -37,10 +37,23 @@ So we want to provide our members with principles that guide them to a smooth de reduce complexity. |G3 -|Simple Solutions -|IT will be as simple as possible. Where complexity -is required it will be encapsulated and hidden -behind a interface that is as simple as possible. +|Keep it simple stupid (KISS) +a|Based on our interpretation of +https://en.wikipedia.org/wiki/Agile_software_development[Agile Development] +we think that we should choose the https://en.wikipedia.org/wiki/KISS_principle[simplest] approach to tackle a task. + + +Particularly, we always try to avoid optimizing things before it turns out +that optimization is needed (https://ubiquity.acm.org/article.cfm?id=1513451[see Donald Knuth]). +This applies, in the same way, to _small_ things eg. + +* optimizing algorithms like SQL-queries +* choosing frameworks for persistence, offering rest endpoints, frontend frameworks +* infrastructural topics like VCS build system + +As well as it applies to "bigger" things eg. + + * Deciding architectural things like using CQRS + * Using microservices vs. putting things into a monolith |G4 |Shared Resources @@ -50,12 +63,22 @@ and data. |G5 |Quality -|A minimum standard of quality will be maintained -despite time to market concerns. +|A minimum standard of quality will be maintained despite time to market concerns. +|G6 +|Favor what is proven +| Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that: + * we are getting more support from other developers if we run into problems + * expect more support from the upstream project itself, and also the project itself will exist for a longer time + * have better tooling support (if applicable) + * have it easier to find more developers + +|G7 +| Match techniques with skills of core team members +| The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it. |=== -=== DATA +=== Data [cols="1,2,6"] |=== @@ -166,40 +189,9 @@ handling of improbable exceptions). |A3 |Bleeding Edge -|Experimental or early release technologies will not +|Experimental or early-release technologies will not be used unless they are critical to competitive advantage. |=== - -== Key drivers for technical decisions - - 1. *Any decision should be as little opinionated as possible* + - We should never choose a technology just because we consider - it as cool or because we have had a good experience with it in _another_ use case. - Decisions should be made depending on the use case. + - 2. *Keep it simple stupid (KISS)* + - Based on our interpretation of - https://en.wikipedia.org/wiki/Agile_software_development[Agile Development] - we think that we should choose the https://en.wikipedia.org/wiki/KISS_principle[simplest] approach to tackle a task. - Particularly, we always try to avoid optimizing things before it turns out - that optimization is needed (https://ubiquity.acm.org/article.cfm?id=1513451[see Donald Knuth]). - This applies, in the same way, to _small_ things eg. - * optimizing algorithms like SQL-queries - * choosing frameworks for persistence, offering rest endpoints, frontend frameworks - * infrastructural topics like VCS build system + -+ -As well as it applies to "bigger" things eg. - * Deciding architectural things like using CQRS - * Using microservices vs. putting things into a monolith - 3. *Best of breed* + - Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that: - * we are getting more support from other developers if we run into problems - * expect more support from the upstream project itself, and also the project itself will exist for a longer time - * have better tooling support (if applicable) - * have it easier to find more developers - 4. *Match techniques with skills of core team members* + - The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it. - -Some criteria could conflict with others. Life is not always easy.