Slide 1

Slide 1 text

qaware.de Vom Elfenbeinturm zur agilen Architektur Mario-Leander Reimer [email protected] @LeanderReimer

Slide 2

Slide 2 text

2 Mario-Leander Reimer Managing Director | CTO @LeanderReimer #cloudnativenerd #qaware #gernperDude

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

1st commandment Thou shalt not use other databases than Oracle!

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

6 QAware

Slide 7

Slide 7 text

7 QAware The Wild Agile West

Slide 8

Slide 8 text

QAware | 8 Architecture in Agile Projects

Slide 9

Slide 9 text

1st commandment Thou shalt sprint 2 weeks, no less or more!

Slide 10

Slide 10 text

10 QAware https://arc42.org/download High-Level Structure of the arc42 Documentation Template

Slide 11

Slide 11 text

Holistic Software Product Quality is a lot of work! QAware | 11 Software Product Quality (ISO 25010) ● Modularity ● Reusability ● Analysability ● Modifiability ● Testability Maintainability ● Confidentiality ● Integrity ● Non-repudiation ● Authenticity ● Accountability Security ● Adaptability ● Installability ● Replaceability Portability ● Co-existence ● Interoperability Compatibility ● Maturity ● Availability ● Fault Tolerance ● Recoverability Reliability ● Time Behaviour ● Resource Utilization ● Capacity Efficiency ● Completeness ● Correctness ● Appropriateness Functional Suitability ● Operability ● Learnability ● UI Aesthetics ● Accessibility Usability Safety Deployability

Slide 12

Slide 12 text

Q42. Ein einfaches und pragmatisches Qualitätsmodell. QAware | 12 https://quality.arc42.org/

Slide 13

Slide 13 text

Die geforderten Qualitäts-Attribute sind auf allen Ebenen einer Software-Architektur zu finden. 13

Slide 14

Slide 14 text

14 QAware Architecture Diagrams

Slide 15

Slide 15 text

4 Maps of your Code: Context. Container. Component. Code. 15 QAware

Slide 16

Slide 16 text

16 Decisions

Slide 17

Slide 17 text

QAware | 17 https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Slide 18

Slide 18 text

Architecture Decision Records (ADR) QAware | 18 https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records

Slide 19

Slide 19 text

The Anatomy of an Architecture Decision Records (ADR) QAware | 19 # Title ## Context ## Decision ## Status ## Consequences ■ Short text file; 1-2 pages long, one file per decision ■ Simple format like Markdown, Asciidoc, TXT, etc. Short noun phrase and number, e.g. ADR 5: AWS as preferred cloud provider Proposed, Accepted, Deprecated, Superseded Describes the forces at play: technology, political, project local. Value neutral, simple facts. Response to the forces with justification. Stated in full sentences, with active voice. "We will …" Describe context, after applying the decision. All consequences should be listed here, not just the "positive" ones.

Slide 20

Slide 20 text

The Last Possible Moment != The Last Responsible Moment QAware | 20 ■ Welche Fragen sind für verantwortungsvolle Entscheidungen relevant? – Muss ich die Entscheidung jetzt treffen? – Kann ich es noch aufschieben? – Was passiert, wenn ich es nicht mache? – Wann wird die Komplexität zu hoch? – Welche Alternativen gibt es? – Was sind die Trade-Offs der Entscheidung? – Kann die Entscheidung rückgängig gemacht werden? ■ The Last Responsible Moment ist die bessere Wahl! ■ Keine Angst vor suboptimalen Entscheidungen. ■ Iterative Entwicklung, Tests, Refactoring, Continuous Integration und Architecture Fitness Functions helfen das Risiko beherrschbar zu machen

Slide 21

Slide 21 text

Architecture Fitness Functions validieren die geforderten (nicht)-funktionalen System-Eigenschaften kontinuierlich. 21 https://www.thoughtworks.com/de/radar/techniques/architectural-fitness-function

Slide 22

Slide 22 text

Fitness-function Driven Development QAware | 22 ■ Architektur ist wie ein Produkt mit User Journeys ■ Anforderungen werden von den Stakeholdern eingesammelt – Business – Compliance – Operations – Security – Infrastructure ■ Das sind häufig unsere „-illities“ und Qualitätsmerkmale ■ Die Akzeptanz-Kriterien werden mit einem BDD Test Framework formuliert. ■ Tests werden als Teil der CI/CD Pipeline ausgeführt, und anschließend verifiziert https://www.thoughtworks.com/de/insights/articles/fitness-function-driven-development

Slide 23

Slide 23 text

Beispiel: Code Quality QAware | 23

Slide 24

Slide 24 text

Beispiel: Performance QAware | 24

Slide 25

Slide 25 text

Beispiel: Security 25 describe "Security" do describe “Static Analysis” do it "should not have plaintext secrets in codebase" do expect(code.has_secrets_in_codebase()).to_not be(true) end end describe “Dynamic Analysis” do it "should not have any of the OWASP Top 10" do expect(zap.has_owasp_top_10_vulnerabilities()).to be(false) end end end

Slide 26

Slide 26 text

Beispiel: Operability 26 QAware

Slide 27

Slide 27 text

27 QAware +

Slide 28

Slide 28 text

Menschen machen Fehler. Von der Clean Architecture zum Big Ball of Mud geht’s schneller, als man glaubt! QAware | 28

Slide 29

Slide 29 text

ArchUnit ermöglicht die einfache automatisierte Prüfung einer Software-Architektur in Form von Unit Tests. ■ https://www.archunit.org/ ■ Freie (Apache v2), einfache und erweiterbare Bibliothek zur Prüfung der Architektur von Java Code. Gibt es auch für .NET/C#. ■ Alle gängigen Build Tools und Unit Test Frameworks werden unterstützt ■ Das ArchUnit Library API bietet eine Sammlung an vordefinierten Regeln für wiederkehrende Architektur-Prüfungen – Architectures: Regeln zur Überprüfung von Layered und Onion Architectures – Slices: Erkennung von “Cycles” auf unterschiedlichen Ebenen – General: Sammlung von Regeln für Good Coding Practices (z.B: Logging, Exceptions, …) – PlantUML: Regeln zum Abgleich der Codebase mit einem PlantUML Modell – Freezing Arch Rules: Erlaubt die Definition einer Baseline für Violations, besonders nützlich um Technische Schulden in Altprojekten zu managen QAware | 29

Slide 30

Slide 30 text

Nur wenige Zeilen Code validieren unsere Clean Architecture kontinuierlich und wiederholbar bei jedem Build. 30 @AnalyzeClasses(packages = {"de.qaware.archunit.example.onion"}) public class OnionArchitectureFitnessTest { @ArchTest static final ArchRule onion_architecture_is_respected = onionArchitecture() .domainModels("..domain.model..") .domainServices("..domain.service..") .applicationServices("..application..") .adapter("cli", "..adapter.cli..") .adapter("persistence", "..adapter.persistence..") .adapter("rest", "..adapter.rest.."); }

Slide 31

Slide 31 text

QAware | 31 Wo gehobelt wird, fallen Späne!

Slide 32

Slide 32 text

aim42 ist super nützlich um technische Schulden regelmäßig und strukturiert zu begegnen und abzubauen. QAware | 32 https://www.aim42.org/

Slide 33

Slide 33 text

“Too much cognitive load will become a bottleneck for fast flow and high productivity for many agile teams.” QAware | 33 ■ Intrinsic Cognitive Load Relates to fundamental aspects and knowledge in the problem space (e.g. used languages, APIs, frameworks) ■ Extraneous Cognitive Load Relates to the environment (e.g. console command, deployment, configuration) ■ Germane Cognitive Load Relates to specific aspects of the business domain (aka. „value added“ thinking)

Slide 34

Slide 34 text

Die Architekturarbeit kann und sollte auf verschiedenen Ebenen und verschiedenen Teams passieren. QAware | 34 https://martinfowler.com/bliki/TeamTopologies.html

Slide 35

Slide 35 text

Beyond "Moderne Software-Architektur". Mein persönliche Leseliste für neue Impulse und Ansätze. 35 QAware

Slide 36

Slide 36 text

qaware.de QAware GmbH Aschauer Straße 32 81549 München Tel. +49 89 232315-0 [email protected] twitter.com/qaware linkedin.com/company/qaware-gmbh xing.com/companies/qawaregmbh slideshare.net/qaware github.com/qaware