# Software Architecture is not a swearword Oliver Zeigermann https://2023.boosterconf.no/program/wednesday/9_short_talks_and_workshops/kongesal_5/28-software-architecture-is-not-a-swearword/ Slides: https://bit.ly/booster-arch-2023 <!-- https://djcordhose.github.io/ml-resources/2023-booster.html --> <img src="img/architecture/bit.ly_booster-arch-2023.png" style="height: 200px;">

### Who is Olli <div style="display: flex;"> <div style="flex: 50%;"> <img src='img/olli-T.jpg' height="400"> </div> <div style="flex: 50%; font-size: x-large;"> <img src='img/olli-opa.jpeg'> </div> </div> <p> <a target="_blank" href="mailto:oliver@zeigermann.de">Oliver Zeigermann</a>: Blue Collar Architect(ML) </p>

### Olli likes Norwegian Music <div style="display: flex;"> <div style="flex: 50%;"> <img src='img/metal/20230228_222556.jpg'> </div> <div style="flex: 50%; font-size: x-large; height: 400px;"> <img src='img/metal/20230228_230245.jpg'> </div> </div> http://www.spidergawd.no/ (also https://www.borknagar.com/)

### Gauge by show of hands What do you think when you think about someone doing architectural work? * Probably can't code * Maybe used to code * Can not go beyond the level of boxes and arrows * Can talk, but not act * Tries to deflect responsibility * What else? What are your experiences? _Please be as open as possible_

Questions and discussions are welcome *at any time*

### Our Challenge for today: predicting risks * We do architectural work for a highly innovative car insurance company. * Unlike other insurance companies, we determine the rate based on the estimated number of accidents per customer. * Objective: how many accidents will the potential customers have? <img src='img/pixabay/accident-151668_1280.png' style="height: 230px">

### Features to draw conclusion from * driver * *training*: 0/1, the driver completed driver training * *age*: Age of the driver in years * vehicle * *emergency_braking*: 0/1, the vehicle has an emergency braking system * *braking_distance*: Braking distance from speed 100 * *power*: Power in KW * *miles*: Annual mileage * to predict * *risk_group*: Classification into group based on risk

### Requirements for our solution 1. *Accuracy* - should have 80% or more cases correct 1. *Explainability* - we need to explain how we come to the conclusion 1. *Stability* - an updated version of the software must be possible should not behave totally different 1. *Hackability* - it should be hard to find out how the software works to resist manipulation 1. *Ressources* - should scale well and not use a lot of resources to run

## Classic Solution: Code ``` if training: return LOW_RISK if age < 30: if power > 130: return HIGH_RISK else: return MEDIUM_RISK if age > 50: return HIGH_RISK if emergency_braking: return LOW_RISK if milage > 50: return HIGH_RISK if milage > 30: return MEDIUM_RISK # default return LOW_RISK ``` if you want this maintainable, you can not make this too complex or too nested

### There are options, though <img src="exercise/solutions.png"> https://ml-playground.com Notes: a) Code mit echtem Code-Beispiel: Wenn tiefer nicht mehr Wartbar und von Hand schreibbar b) Decision Tree c) K-Nearest Neighbors d) Deep Learning

## Hands-On: Choose a suitable solution ### 45 Minutes <div class="container"> <div class="col"> ### Decide _Choices to make_ 1. Code or Data Driven 1. If data driven, which ML approach? 1. Experiment with the playground if needed 1. Ask Olli if you need further information </div> <div class="col"> ### Document _Document your decision_ - Assumptions - Compromises - Inferred priorities - etc. Choose whatever form you see fit for documentation </div> </div> *Pair up in teams of at least two and at most four people*

### Reflection 1. What kind of documentation did you write? * Did you feel comfortable with the form chosen? * Did you really have a choice? 1. How did you feel wile making your decision? * Did you feel stressed? What stressed you out? * Did you feel up to the task of making a choice in the first place? * Who was lacking deeper technical insights? * Who wanted more emotional support?

### Challenges: Typical things happening in production 1. Smartass Lawyer Attack * can you explain your decision? 1. price comparison service tries to outsmart you * are you prone to adversarial attacks 1. Drift * driver assistance becomes prevalent - prediction of risk no longer valid * are you able to create a stable new model 1. Investigative Journalism * there might be systematic age bias _How would they affect your decision?_ - Does the documentation help? - What assumptions have been invalidated?

# But ## How is this related to software architecture?

### (Software) Architecture * the important decisions, whatever they are * once taken they are often hard to change * often have to be made early in a project * require compromise * if being bad have the potential to make the project fail * there always are important decisions * if you don't choose explicitly, there always is on implicit choice _there are other definitions, but this is the definition we use today_ https://martinfowler.com/architecture

### Architectural Work _under high uncertainty and imperfect information ..._ 1. find areas of important decisions (often solely based on experience and gut feeling) 1. match * (partially contradicting and incomplete or even only implicit) requirements - given by domain expert role - with * (vague) properties of (a mostly arbitrary selection of) architectural patterns / frameworks - given by technical expert role * while inferring priorities (because no one wants to give them) by making assumptions

### Some areas of important technical decisions in a business app <img src="img/architecture/areas.jpg"> _We leave out the areas of people and administration for today (even though they are at least as important)_

### Today we deal with business logic <img src="img/architecture/logic.jpg"> _Might not be obvious, but is can be an architectural decision_

### Why document? 1. Making things explicit * making sure proper reasoning has been done in the first place * provide a basis for discussion 1. Reference * something used by developer roles to actually make the software * for people coming back into the project at a later point * having your back 1. Requirements change or get more obvious and explicit over time - we can not look into the future * If this happens do we know what decision we took based on what perceived requirement and assumption? _most of this gets invalidated when documentation is dishonest_

### What to document? <img src="img/architecture/docs.jpg">

### How to document? <img src="img/architecture/lightweight-docs.jpg"> Don't make it a legal text - unless you really have to

## Why is this so hard?

### The Job itself is just hard <img src="img/architecture/why-hard.jpg">

### Software Architecture is a creative task * first phase of a project is full of unknown unknowns * how to find the important questions (not even the answers) is a creative process * requires mental and emotional resilience

### What is the set of options you are choosing from as architectural pattern? - even obscure solutions can be successful - How Levels.fyi scaled to millions of users with Google Sheets as a backend - https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html - https://twitter.com/auchenberg/status/1627359937432023041?s=20

### You need to earn respect as a software architect _As an architect you need to have a certain level of technical understanding_ * implementation is key * without it you have a PowerPoint and not software * need to have an idea what the boxes and arrows represent * what technology can be used to implement them * what effort is required * for the details you might need to consult with an engineering role who is more into it * it might require you to take basic courses in technology used for implementation (no matter how senior you are)

### Conclusion *Architecture can be defined as the sum of important decisions, but* <img src="img/architecture/conclusion.jpg">

# Thanks a lot ## Software Architecture is not a swearword Stay in Contact https://www.linkedin.com/in/oliver-zeigermann-34989773/ oliver@zeigermann.de Twitter: @DJCordhose Slides: https://bit.ly/booster-arch-2023