Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Good Enough Architecture

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.

Stefan Tilkov

November 07, 2019
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. “Good Enough”
    Architecture
    Stefan Tilkov
    [email protected]
    @stilkov
    O’Reilly SACon Berlin, 2019
    "Tegel Airport TXL Berlin May 2012 - 19" by andynash is licensed under CC BY-SA 2.0

    View full-size slide

  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)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. Pick the best car:

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. #1: Non-extensible Extensibility

    View full-size slide

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

    View full-size slide

  12. @stilkov
    Large
    customers

    (“strategic”)
    Small
    customers

    (“long tail”)
    Specific
    General
    High
    Low
    (Acceptable)

    Cost
    Customization

    (Need)
    The
    Solution

    View full-size slide

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

    View full-size slide

  14. @stilkov
    Highly specific code is often preferable to
    sophisticated configuration

    View full-size slide

  15. #2: Perilously Fine Granularity

    View full-size slide

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

    View full-size slide

  17. @stilkov
    Team 1
    Team 3
    Team 2

    View full-size slide

  18. @stilkov
    Order Service
    Support Fulfillment Billing
    Checkout

    View full-size slide

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

    View full-size slide

  20. @stilkov
    Everybody wants to be Netflix, but nobody is

    View full-size slide

  21. @stilkov
    Order Service
    Support Fulfillment Billing
    Checkout

    View full-size slide

  22. @stilkov
    Support Fulfillment Billing
    Checkout
    Order Service

    View full-size slide

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

    View full-size slide

  24. #3: Your system WILL be dynamic

    View full-size slide

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

    View full-size slide

  26. @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

    View full-size slide

  27. @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

    View full-size slide

  28. @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

    View full-size slide

  29. #4: Horizontal Conway Split

    View full-size slide

  30. @stilkov
    Context
    • Unified communication platform
    • Straight-forward business logic
    • High scaling requirement
    • 1-2 teams/10-20 developers

    View full-size slide

  31. @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«

    View full-size slide

  32. @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

    View full-size slide

  33. @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

    View full-size slide

  34. @stilkov
    Mel Conway (@conways_law, follow him)
    is right most of the time

    View full-size slide

  35. @stilkov
    There are no limits to architectural complexity
    people will accept to stay among their own

    View full-size slide

  36. #5: System of Systems

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  41. @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

    View full-size slide

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

    View full-size slide

  43. #6: Free-style Architecture

    View full-size slide

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

    View full-size slide

  45. @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

    View full-size slide

  46. @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

    View full-size slide

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

    View full-size slide

  48. #7: Cancerous Growth

    View full-size slide

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

    View full-size slide

  50. @stilkov
    Oracle DB
    Oracle Forms App

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  53. @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

    View full-size slide

  54. @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

    View full-size slide

  55. @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

    View full-size slide

  56. @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

    View full-size slide

  57. @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

    View full-size slide

  58. #8: Improve with Less Intelligence

    View full-size slide

  59. @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

    View full-size slide

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

    View full-size slide

  61. @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

    View full-size slide

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

    View full-size slide

  63. @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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  67. @stilkov
    3.
    Create evolvable structures

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  70. @stilkov
    Stefan Tilkov
    @stilkov
    [email protected]
    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!

    View full-size slide

  71. Rate today ’s session
    Session page on conference website O’Reilly Events App

    View full-size slide

  72. @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

    View full-size slide

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

    View full-size slide

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

    View full-size slide