Good Enough Architecture

Afd6dc452bc20f8f06612d4792bb8be3?s=47 Stefan Tilkov
November 07, 2019

Good Enough Architecture

Stefan Tilkov takes a look at some of the ways you can determine whether the development efforts you’re undertaking suffer from too much or too little focus on architecture. You’ll examine a number of real-world examples that are intended to inspire either admiration or terror and try to find some recipes of how you can get more of the former and less of the latter in your own projects.

Afd6dc452bc20f8f06612d4792bb8be3?s=128

Stefan Tilkov

November 07, 2019
Tweet

Transcript

  1. “Good Enough” Architecture Stefan Tilkov stefan.tilkov@innoq.com @stilkov O’Reilly SACon Berlin,

    2019 "Tegel Airport TXL Berlin May 2012 - 19" by andynash is licensed under CC BY-SA 2.0
  2. @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)
  3. @stilkov Architecture is not an upfront activity performed by somebody

    in charge of telling everyone else what to do
  4. @stilkov Architecture is a property of a system, not a

    description of its intended design
  5. Pick the best car:

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

  7. 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
  8. @stilkov There is no “good” or “bad” architecture without context;

    architecture needs to take specific quality attributes into account
  9. Cases

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

  11. #1: Non-extensible Extensibility

  12. @stilkov Context • E-Commerce (retail) provider • Global customer base

    • Catalog/CMS/Shop/Fulfillment • Multi-tenant • Highly customizable
  13. @stilkov Large customers
 (“strategic”) Small customers
 (“long tail”) Specific General

    High Low (Acceptable)
 Cost Customization
 (Need) The Solution
  14. @stilkov If your design attempts to satisfy everyone, you’ll likely

    end up satisfying no one
  15. @stilkov Highly specific code is often preferable to sophisticated configuration

  16. #2: Perilously Fine Granularity

  17. @stilkov Context • Large-scale B2B food retailer • New company-wide

    shop and logistics system • >200 developers
  18. @stilkov Team 1 Team 3 Team 2

  19. @stilkov Order Service Support Fulfillment Billing Checkout

  20. Why would you cut up your system into tiny, distributed,

    hard-to- manage fragments?
  21. @stilkov Everybody wants to be Netflix, but nobody is

  22. @stilkov

  23. @stilkov …

  24. @stilkov Order Service Support Fulfillment Billing Checkout

  25. @stilkov Support Fulfillment Billing Checkout Order Service

  26. @stilkov Lessons learned • Small is not always beautiful •

    Refactoring within team boundaries much easier than globally • Ignore organizational parameters at your own risk
  27. #3: Your system WILL be dynamic

  28. @stilkov Context • Large-scale insurance system • Model-driven development •

    > 100 developers • 2 Releases/year
  29. @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
  30. @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 …
  31. @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
  32. #4: Horizontal Conway Split

  33. @stilkov Context • Unified communication platform • Straight-forward business logic

    • High scaling requirement • 1-2 teams/10-20 developers
  34. @stilkov Group 1 Motto: »Java is a legacy programming language

    used in the last century« Group 2 Motto: »Obviously, you can’t build correct programs with JavaScript«
  35. @stilkov Group 1 Motto: »Java is a legacy programming language

    used in the last century« Group 2 Motto: »Obviously, you can’t build correct programs with JavaScript« HTML/CSS/JavaScript Frontend Java Backend JSON API
  36. @stilkov Lessons learned • Every meaningful feature development required frontend

    and backend parts, and thus co-operation between teams • When faced with unresponsive backend teams, frontend teams quickly become secret full-stack teams
  37. @stilkov Mel Conway (@conways_law, follow him) is right most of

    the time
  38. @stilkov There are no limits to architectural complexity people will

    accept to stay among their own
  39. #5: System of Systems

  40. @stilkov Context • E-Commerce/Online shop (Retail) • 100-120 developers •

    ~10 self-contained teams
  41. @stilkov number of developers strength of decoupling methods modules components

    μservices systems
  42. @stilkov From a layered system … System Logic Data UI

    Module Module Module
  43. @stilkov … to a system of systems System System System

    Logic Data UI Logic Data UI Logic Data UI
  44. @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
  45. @stilkov Extremely loose coupling requires very few rules, but they

    need to be enforced strictly
  46. #6: Free-style Architecture

  47. @stilkov Context • E-Commerce/Online shop (Retail) • 100-120 developers •

    ~10 self-contained teams
  48. @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
  49. @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
  50. @stilkov There’s a fine line between diversity (that adds value)

    and chaos (that doesn’t)
  51. #7: Cancerous Growth

  52. @stilkov Context • Financial services provider with independent brokers as

    clients • ~30 developers • 20 years of company history
  53. @stilkov Oracle DB Oracle Forms App

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

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

    Web Service .NET Web Service .NET Web Service .NET Web Service
  56. @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
  57. @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
  58. @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
  59. @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
  60. @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
  61. #8: Improve with Less Intelligence

  62. @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
  63. @stilkov Magical Integration Broker Custom App CotS DB External Partner

    Other Group Company Parent Company External Partner Custom App Custom App CotS
  64. @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 …
  65. @stilkov Custom App CotS DB External Partner Other Group Company

    Parent Company External Partner Custom App Custom App CotS Pub/Sub Messaging
  66. @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
  67. @stilkov Lessons learned • Smart endpoints, dumb pipes (cf. Jim

    Webber) • Value of specific over generic solutions • Micro architecture with blueprints
  68. Takeaways

  69. @stilkov 1. Don’t be afraid of architecture

  70. @stilkov 2. Choose the simplest thing that will work

  71. @stilkov 3. Create evolvable structures

  72. @stilkov 4. Manage your system’s architectural evolution

  73. @stilkov 5. Don’t build road blocks – create value and

    get out of the way
  74. @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!
  75. Rate today ’s session Session page on conference website O’Reilly

    Events App
  76. @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
  77. @stilkov Growing architectural maturity means less guidance and rules are

    needed
  78. @stilkov The more experienced you are at (active and passive)

    architectural governance, the less you can do of it