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

Democratising Software Architecture

Democratising Software Architecture

Today’s mainstream acceptance of Agile+DevOps as the preferred way of working once again raises questions of what architecture work is and who does it. It simultaneously challenges much of our previously accepted wisdom, preferring architecture to be a “shared commons” across the development organisation, while demanding a sophisticated level of software architecture practice to deliver on the promises of Agile+DevOps.

One way of describing this situation is the need to “democratise” software architecture so it becomes a shared responsibility rather than a centralised impediment to rapid delivery. In this talk we’ll examine the challenges of software architecture in today’s modern distributed teams and ask how we might make the architecture of their systems a shared responsibility to allow them to achieve the software architecture that they need at the speed that they need it.

Eoin Woods

March 29, 2019
Tweet

More Decks by Eoin Woods

Other Decks in Programming

Transcript

  1. Democratising
    Software Architecture
    Eoin Woods
    Endava
    @eoinwoodz
    ICSA 2019, Hamburg, March 2019
    1

    View Slide

  2. Eoin Woods
    • Endava’s CTO, based in London
    • 10+ years in product dev - Bull, Sybase, InterTrust
    • 10 years in capital markets applications - UBS and BGI
    • Software engineer, then architect, now CTO
    • Software engineer in theory & practice (BSc, MSc, recently PhD)
    • Author, editor, speaker, community guy

    View Slide

  3. 3
    DISCLAIMER
    These are my views based on my experience
    in the domains I have worked in.
    Others may differ in their views !

    View Slide

  4. EVOLVING SOFTWARE ARCHITECTURE
    4

    View Slide

  5. 5 ages of software Systems
    Intelligent
    Connected
    (2020s)
    Internet
    is the System
    (2010s)
    Internet
    Connected
    (2000s)
    Distributed
    Monoliths
    (1990s)
    Monolithic
    (1980s)

    View Slide

  6. Architecture has changed too
    Computing Era Architecture Concern
    Monolithic Era => Structuring programs
    Distributed Monoliths Era => Architecture emerges
    Internet-Connected Era => Quality properties
    Internet-is-the-System Era => Architecture at speed
    Intelligent Connected Era => … ?

    View Slide

  7. Historical Context
    • Central small group
    • Organisation of large pieces
    • Relatively static connections
    • Largely completed before
    implementation
    • Structures, qualities,
    stakeholders, technology choices
    7
    https://donmaclennan.com/

    View Slide

  8. What has changed?
    8
    FLUID
    EVOLVING
    ARCHITECTURE
    DevOps
    Microservices
    Cloud
    Agile

    View Slide

  9. What is the problem?
    9
    ? ?
    !!
    ?
    !!
    !! ? !!

    View Slide

  10. Our traditional model is of less value
    • Constant evolution => less ”certainty” early in lifecycle
    • Less decided early in lifecycle =>
    less value in thorough ”up front” architecture
    10
    • Autonomous teams => independent activity
    • Independent activity => constant parallel decision making
    • Constant decisions => architect overload => blocks progress

    View Slide

  11. Is architecture still needed?
    11
    • Difficult quality attributes
    • Stakeholders don’t go away
    • Still have tradeoffs
    • Cross cutting concerns across
    many independent elements
    • BUT traditional ”structural”
    focus may need to change
    Cross-Cutting Concerns
    Tradeoffs
    Stakeholders
    Quality
    Attributes
    Yes!

    View Slide

  12. WHAT PRACTITIONERS DO
    12

    View Slide

  13. Software Architecture in Practice
    • Empowered cross-functional teams
    • Less “architects” more “engineers”
    • Lightweight description – C4, ADRs
    • Code Analysis – dependency visibility
    • Runtime Analysis – dependency visibility, trends
    • Informal description – Wiki, PowerPoint, Visio
    • Modelling – occasional use of UML and Archimate
    13

    View Slide

  14. C4 Model
    • Simon Brown’s accessible 4-view
    model for software architecture
    • Context
    • Containers
    • Component
    • Code (class diagram - optional)
    • Optional Landscape, Dynamic
    and Deployment views
    • Structurizr tool
    • Widely recognized in industry
    14
    c4model.com

    View Slide

  15. Architecture Decision Records

    Old idea “rediscovered” by
    Michael Nygard in 2011

    Simple textual decision records
    using templates

    Stored with the code

    Nygard’s form:

    Title, Status, Context, Decision &
    Consequences
    15
    thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
    github.com/joelparkerhenderson/architecture_decision_record

    View Slide

  16. Code Analysis
    • Generally static code analysis
    • Open source tools dominate
    • SonarQube in particular
    • “Code doesn’t lie”
    • Main architectural aspect is
    dependency analysis
    16

    View Slide

  17. Runtime Analysis
    • Response to dynamic nature of
    microservices
    • Distributed monitoring & tracing
    • Jaeger, Zipkin
    • Prometheus + Grafana
    • Log aggregation & analysis - ELK
    • AppDynamics & NewRelic
    • “Production is reality”
    17

    View Slide

  18. Visio, PowerPoint, Wiki, …
    • Where most ADs end up
    • Quality varies from useless to
    very valuable
    • Familiar & highly accessible
    • Usually custom syntax and
    semantics
    • Interpretation, precision and
    consistency often limited
    18

    View Slide

  19. Modelling: UML and Archimate
    • Rare choice today
    • Their genericity is a difficulty
    • UML good base for a DSL … but
    significant investment needed
    • Archimate useful for EA but not
    really solution or software arch
    • Tools can get in the way
    • Can actually be a
    communication barrier
    19

    View Slide

  20. A NEW APPROACH
    20

    View Slide

  21. 21
    Architecture is a skill not a role
    Principles, styles & patterns over structures
    Delegate & share wherever possible
    ”Little and often” (and adapt)
    Aim for “shared commons”
    Stream of decisions, not “one off” architecture
    Architecture
    Work in the
    New World

    View Slide

  22. 22
    Architecture work in every sprint
    Decisions, principles, styles, patterns
    Deliver decisions as they are needed
    Form an inclusive architecture group
    Practical tests to validate architecture work
    Keep the architecture ”close to the code”
    Key
    Practices

    View Slide

  23. 23
    RDCA
    (Risk & Cost
    Driven
    Architecture)
    Eltjo Poort, CGI
    eltjopoort.nl

    View Slide

  24. Architecturally Evident Code
    • George Fairbanks
    • Code reflects the architecture
    • Names, structures line up
    • Changes code packaging
    • Can affect testing
    • Often “messes up” architecture!
    • Can be hard to check
    • ArchUnit
    24

    View Slide

  25. Common Problems
    • Sharing and managing architecture information (AKM)
    • Lack of artefacts => misunderstanding, knowledge loss
    • Understanding the system-wide view
    • Resistance to any design work (“we’re agile”)
    • Desire for a ”complete” architecture up front
    • Enterprise architects (!)
    25

    View Slide

  26. FOR RESEARCH
    26

    View Slide

  27. Research vs Practice Disconnection
    RESEARCH PRACTICE
    Models and theories Technologies, patterns, code
    Architecture as separate activity Architecture as dev activity
    Completed architecture Just enough architecture
    Solving idealised problems Focus on today’s delivery
    Papers, academic conferences Github, blogs, conferences
    Validation via small survey Validation by production operation
    27

    View Slide

  28. Some Suggestions
    WHILE PLANNING WHILE RESEARCHING
    Link to industry projects Prioritise flow of change to
    production
    Understand practice through OSS Codify ideas in code, patterns,
    templates
    Watch industry event topics* Be sensitive to adoption effort vs
    validation level
    Attend industry events* Be aware of standard tools
    Consider motivation & validation
    28
    * QCON, SATURN, DevTernity, JAX, NDC, …

    View Slide

  29. TO CONCLUDE
    29

    View Slide

  30. Software development is changing:
    so will software architecture
    30
    Agile + DevOps
    change how we WORK
    Cloud + Containers
    change how we BUILD
    Less “Upfront” Architecture
    Quality Attributes, Tradeoffs, Stakeholders
    Flow Of Decisions & Guidance
    Changes to Architect’s Work
    Changes to Architect Training

    View Slide

  31. Architect: From Purveyor of Wisdom …
    31

    View Slide

  32. … to Trusted Leader and Advisor
    32

    View Slide

  33. Eoin Woods
    Endava
    [email protected]
    @eoinwoodz
    33
    THANK YOU …

    View Slide