Tweet
Tweet

Slide 1

Slide 1 text

“Good Enough” Architecture Stefan Tilkov stefan.tilkov@innoq.com @stilkov GOTO Berlin 2019 "Tegel Airport TXL Berlin May 2012 - 19" by andynash is licensed under CC BY-SA 2.0

Slide 2

Slide 2 text

@stilkov (Software) Architecture Definitions Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO 42010) Whatever the architect considers important enough to merit their attention Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change (Grady Booch)

Slide 3

Slide 3 text

@stilkov Architecture is not an upfront activity performed by somebody in charge of telling everyone else what to do

Slide 4

Slide 4 text

@stilkov Architecture is a property of a system, not a description of its intended design

Slide 5

Slide 5 text

Pick the best car:

Slide 6

Slide 6 text

@stilkov Quality https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

Slide 7

Slide 7 text

Scaling Dimensions Logic Load written in a day depends on German tax law a dozen users half of the planet Netflix Twitter Insurance Policy Management Facebook Amazon Random CMS

Slide 8

Slide 8 text

@stilkov There is no “good” or “bad” architecture without context; architecture needs to take specific quality attributes into account

Slide 9

Slide 9 text

Cases

Slide 10

Slide 10 text

@stilkov Context: • … Observation(s): • … Lesson(s) learned: • …

Slide 11

Slide 11 text

#1: Non-extensible Extensibility

Slide 12

Slide 12 text

@stilkov Context • E-Commerce (retail) provider • Global customer base • Catalog/CMS/Shop/Fulfillment • Multi-tenant • Highly customizable

Slide 13

Slide 13 text

@stilkov Large customers
 (“strategic”) Small customers
 (“long tail”) Specific General High Low (Acceptable)
 Cost Customization
 (Need) The Solution

Slide 14

Slide 14 text

@stilkov If your design attempts to satisfy everyone, you’ll likely end up satisfying no one

Slide 15

Slide 15 text

@stilkov Highly specific code is often preferable to sophisticated configuration

Slide 16

Slide 16 text

#2: Perilously fine-grained

Slide 17

Slide 17 text

@stilkov Context • Large-scale B2B food retailer • New company-wide shop and logistics system • >200 developers

Slide 18

Slide 18 text

@stilkov Team 1 Team 3 Team 2

Slide 19

Slide 19 text

@stilkov Order Service Support Fulfillment Billing Checkout

Slide 20

Slide 20 text

Why would you cut up your system into tiny, distributed, hard-to- manage fragments?

Slide 21

Slide 21 text

@stilkov Everybody wants to be Netflix, but nobody is

Slide 22

Slide 22 text

@stilkov

Slide 23

Slide 23 text

@stilkov …

Slide 24

Slide 24 text

@stilkov Order Service Support Fulfillment Billing Checkout

Slide 25

Slide 25 text

@stilkov Support Fulfillment Billing Checkout Order Service

Slide 26

Slide 26 text

@stilkov Lessons learned • Small is not always beautiful • Refactoring within team boundaries much easier than globally • Ignore organizational parameters at your own risk

Slide 27

Slide 27 text

#3: Your system WILL be dynamic

Slide 28

Slide 28 text

@stilkov Context • Large-scale insurance system • Model-driven development • > 100 developers • 2 Releases/year

Slide 29

Slide 29 text

@stilkov Modeling Business Concept 0 3 6 4 5 2 1 Technical Concept Implementation Module Test Integration Test Rollout Vision What if you miss your slot? Modeling

Slide 30

Slide 30 text

@stilkov Policy Holder Clause - id - value - dueDate - name - address - status - text - validity - taxClass * * regionCode Model Name New Name (Meaning) Description Release Introduced taxClass regionCode … 10.3 …

Slide 31

Slide 31 text

@stilkov Lessons learned • Centralized responsibility hurts • Faced with too much rigidity, a way around the rules will be found • Just because you’re used to it doesn’t mean it’s acceptable

Slide 32

Slide 32 text

#4: Free-style architecture

Slide 33

Slide 33 text

@stilkov Context • E-Commerce/Online shop (Retail) • 100-120 developers • ~10 self-contained teams

Slide 34

Slide 34 text

@stilkov number of developers strength of decoupling methods modules components μservices systems

Slide 35

Slide 35 text

@stilkov From a layered system … System Logic Data UI Module Module Module

Slide 36

Slide 36 text

@stilkov … to a system of systems System System System Logic Data UI Logic Data UI Logic Data UI

Slide 37

Slide 37 text

@stilkov In-page Cross-page JavaScript method calls Links & redirects Shared abstractions & frameworks Micro-architecture Common language runtime HTTP HTML 5 JS platform Standard Browser

Slide 38

Slide 38 text

@stilkov But … • Lack of standardization led to inefficient UI integration at runtime • Vast differences in API style, formats, documentation created needless extra work • Despite no centralised frontend, a central frontend team created a new bottle neck

Slide 39

Slide 39 text

@stilkov You cannot decide to not have an architecture; if you don’t actively create it, be prepared to deal with the one that emerges

Slide 40

Slide 40 text

@stilkov There’s a fine line between diversity (that adds value) and chaos (that doesn’t)

Slide 41

Slide 41 text

@stilkov Extremely loose coupling requires very few rules, but they need to be enforced strictly

Slide 42

Slide 42 text

#5: Cancerous Growth

Slide 43

Slide 43 text

@stilkov Context • Financial services provider with independent brokers as clients • ~30 developers • 20 years of company history

Slide 44

Slide 44 text

@stilkov Oracle DB Oracle Forms App

Slide 45

Slide 45 text

@stilkov Oracle DB Java/JSP Web App Lots of PL/SQL

Slide 46

Slide 46 text

@stilkov Oracle DB Java/JSP Web App Lots of PL/SQL .NET Web Service .NET Web Service .NET Web Service .NET Web Service

Slide 47

Slide 47 text

@stilkov Oracle DB Java/JSP Web App Lots of PL/SQL .NET Web Service .NET Web Service .NET Web Service .NET Web Service Oracle DB Java/JSP Web App Lots of PL/SQL .NET Web Service .NET Web Service .NET Web Service .NET Web Service Company A Company B

Slide 48

Slide 48 text

@stilkov Java/JSP Web App Lots of PL/SQL .NET Web Service .NET Web Service .NET Web Service .NET Web Service Oracle DB Java/JSP Web App Lots of PL/SQL .NET Web Service .NET Web Service .NET Web Service .NET Web Service Company A Company B

Slide 49

Slide 49 text

@stilkov Java/JSP Web App .NET Web Service .NET Web Service .NET Web Service .NET Web Service Oracle DB Java/JSP Web App .NET Web Service .NET Web Service .NET Web Service .NET Web Service Company A Company B Mongo Couch/Pouch Mongo MySQL

Slide 50

Slide 50 text

@stilkov Java/JSP Web App .NET Web Service .NET Web Service .NET Web Service .NET Web Service Oracle DB Java/JSP Web App .NET Web Service .NET Web Service .NET Web Service .NET Web Service Company A Company B Mongo Couch/Pouch Mongo MySQL C++ Encryption Lib

Slide 51

Slide 51 text

@stilkov Lessons learned • Successful systems often end up the worst architecture • Unmanaged evolution will lead to complete chaos • Don’t be afraid of some light architectural governance

Slide 52

Slide 52 text

#6: Improve with less intelligence

Slide 53

Slide 53 text

@stilkov Context • Bank with multiple CotS systems • Highly proprietary integration solution phased out by vendor • Project launched to replace commercial product with open source solution

Slide 54

Slide 54 text

@stilkov Magical Integration Broker Custom App CotS DB External Partner Other Group Company Parent Company External Partner Custom App Custom App CotS

Slide 55

Slide 55 text

@stilkov Magical Integration Broker Custom App CotS DB External Partner Other Group Company Parent Company External Partner Custom App Custom App CotS Magical Integration Broker Routing Conversion Transformation Transcoding Transport Error handling Business logic …

Slide 56

Slide 56 text

@stilkov Custom App CotS DB External Partner Other Group Company Parent Company External Partner Custom App Custom App CotS Pub/Sub Messaging

Slide 57

Slide 57 text

@stilkov Custom App CotS DB External Partner Other Group Company Parent Company External Partner Custom App Custom App CotS Pub/Sub Messaging Pub Sub Messaging Pub/Sub routing Transport Error handling Adapter (Docker Container) Conversion Transformation Transcoding Error handling Business logic

Slide 58

Slide 58 text

@stilkov Lessons learned • Smart endpoints, dumb pipes (cf. Jim Webber) • Value of specific over generic solutions • Micro architecture with blueprints

Slide 59

Slide 59 text

Takeaways

Slide 60

Slide 60 text

@stilkov 1. Don’t be afraid of architecture

Slide 61

Slide 61 text

@stilkov 2. Choose the simplest thing that will work

Slide 62

Slide 62 text

@stilkov 3. Create evolvable structures

Slide 63

Slide 63 text

@stilkov 4. Manage your system’s architectural evolution

Slide 64

Slide 64 text

@stilkov 5. Don’t build road blocks – create value and get out of the way

Slide 65

Slide 65 text

@stilkov Stefan Tilkov @stilkov stefan.tilkov@innoq.com Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16 80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have. Thanks for listening!

Slide 66

Slide 66 text

@stilkov www.innoq.com OFFICES Monheim Berlin Offenbach Munich Hamburg Zurich FACTS ~150 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups

Slide 67

Slide 67 text

@stilkov Growing architectural maturity means less guidance and rules are needed

Slide 68

Slide 68 text

@stilkov The more experienced you are at (active and passive) architectural governance, the less you can do of it