integrated tech decision principles

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.