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

Cultivating Architecture

Cultivating Architecture

Many organizations today strive to establish autonomous development teams who can move as independently of each other as possible. The goal is to achieve speed and scalability - but what does architecture governance look like in such a decentralised setup? We’ll discuss how to keep everybody aligned on a shared understanding of the architecture and thus avoid prescriptive standardisation without getting chaos.

Birgitta Boeckeler

May 09, 2019
Tweet

More Decks by Birgitta Boeckeler

Other Decks in Technology

Transcript

  1. CULTIVATING ARCHITECTURE
    Birgitta Böckeler @birgitta410 | Martin Fowler @martinfowler

    View Slide

  2. CULTIVATING ARCHITECTURE
    What?

    View Slide

  3. http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

    View Slide

  4. Shared understanding
    Hard to change
    The important stuff
    … whatever that is

    View Slide

  5. CULTIVATING ARCHITECTURE
    Why?

    View Slide

  6. Cumulative
    features
    Time
    No / Poor Architecture
    Good Architecture

    View Slide

  7. CULTIVATING ARCHITECTURE

    View Slide

  8. https://agilemanifesto.org/

    View Slide

  9. Autonomy
    Trust
    Voice
    Westrum
    Organizational
    Culture
    Software
    Delivery
    Performance
    Organizational
    Performance
    Forsgren et al, State of DevOps Report 2018
    https://cloudplatformonline.com/2018-state-of-devops.html
    predictive relationship

    View Slide

  10. “We need some governance”

    View Slide

  11. manipulate
    control
    rule
    restrain
    guide
    serve as
    deciding principle
    have decisive
    influence
    Exert a determining or
    guiding influence
    to govern

    View Slide

  12. guide
    serve as
    deciding principle
    have decisive
    influence
    Exert a determining or
    guiding influence
    rule
    to govern

    View Slide

  13. Business
    Architecture
    Requirements
    Decisions
    Practices
    Principles

    View Slide

  14. Organization
    Unit Unit Unit
    Team Team Team Team Team Team Team Team Team

    View Slide

  15. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  16. Push & pull the
    business context

    View Slide

  17. View Slide

  18. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  19. Architecture
    Requirements

    View Slide

  20. Accessibility
    Auditability
    Availability
    Compliance
    Configurability
    Data integrity
    Distributability
    Extensibility
    Internationalization
    Monitoring
    Performance
    Portability
    Resilience / Fault
    Tolerance
    Scalability
    Security
    Supportability
    Usability
    Upgradability
    Responsiveness
    Testability
    Recoverability
    Data Privacy
    Find your focus

    Traceability

    View Slide

  21. Prioritise
    Offline
    Availability
    Portability
    Data
    privacy


    View Slide

  22. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  23. https://www.slideshare.net/EoinWoods1/using-software-architecture-principles-in-practice
    “A declarative statement made with the intention
    of guiding architectural design decisions in order
    to achieve one or more qualities of a system.”
    - Eoin Woods
    Architecture Principles

    View Slide

  24. Statement
    Team
    Decisions System
    Qualities
    Team
    Decisions
    Team
    Decisions
    Team
    Decisions
    guide lead to
    Require-
    ments

    View Slide

  25. http://engineering-principles.onejl.uk/
    “A declarative statement made with the
    intention of guiding architectural
    design decisions in order to achieve one
    or more qualities of a system.”

    View Slide

  26. http://engineering-principles.onejl.uk/
    http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html
    in order to achieve one or more
    qualities of a system.
    made with the intention of guiding
    architectural design decisions
    A declarative statement

    View Slide

  27. http://engineering-principles.onejl.uk

    View Slide

  28. Sam Newman, “Building Microservices”
    Rationale
    Implications

    View Slide

  29. Facts over
    Opinions
    Hypothesis-driven
    development
    Data
    democratization
    Enter new
    market X
    Customer
    centricity

    View Slide

  30. Authorizations are
    role-based
    Eliminate
    integration
    databases
    Do ongoing user
    research
    Design for Pace of
    Change
    Build
    Differentiators
    Open Integration
    Standards
    Reusable
    Components
    Scale Horizontally
    Cloud Native
    Production Ready
    Automate
    Repetitive Tasks
    Clean Code
    Continuous
    Delivery
    Consistent
    Environments
    Maintainability
    Performance
    Importance
    Release Early and
    Often
    Security First
    Loosely Coupled
    Security,
    Compliance and
    Data Privacy
    AWS First
    Be Bold
    Data-driven/
    metric-driven
    Infrastructure as
    Code
    Have a
    multidisciplinary
    team
    Eliminate accidental
    complexity
    Consistent
    interfaces and data
    flows
    Small and Simple
    Smarts in the
    Nodes, not the
    Network
    Encapsulate legacy
    Minimal
    customisation of
    COTS/SaaS
    Organise around
    Business
    Capabilities
    Consolidate and
    cleanse data
    Minimize
    technology
    variation
    Cleaning is part of
    work well done
    You build it, you
    run it
    Apply principle of
    least privileges
    Data is a shared
    asset
    Small independent
    services
    Facts over Opinions
    Autonomy over
    Economies of Scale
    Decisions at latest
    responsible
    moment
    Single Source of
    Truth
    Data freshness
    Domain Integrity
    Sensitive data are
    exchanged securely
    Existing
    experiences over
    different variations
    Asynchronous
    interactions over
    synchronous coupling

    View Slide

  31. Authorizations are
    role-based
    Eliminate
    integration
    databases
    Do ongoing user
    research
    Design for Pace of
    Change
    Build
    Differentiators
    Open Integration
    Standards
    Reusable
    Components
    Scale Horizontally
    Cloud Native
    Production Ready
    Automate
    Repetitive Tasks
    Clean Code
    Continuous
    Delivery
    Consistent
    Environments
    Maintainability
    Performance
    Importance
    Release Early and
    Often
    Security First
    Loosely Coupled
    Security,
    Compliance and
    Data Privacy
    AWS First
    Be Bold
    Data-driven/
    metric-driven
    Infrastructure as
    Code
    Have a
    multidisciplinary
    team
    Eliminate accidental
    complexity
    Consistent
    interfaces and data
    flows
    Small and Simple
    Smarts in the
    Nodes, not the
    Network
    Encapsulate legacy
    Minimal
    customisation of
    COTS/SaaS
    Organise around
    Business
    Capabilities
    Consolidate and
    cleanse data
    Minimize
    technology
    variation
    Cleaning is part of
    work well done
    You build it, you
    run it
    Apply principle of
    least privileges
    Data is a shared
    asset
    Small independent
    services
    Facts over Opinions
    Autonomy over
    Economies of Scale
    Decisions at latest
    responsible
    moment
    Single Source of
    Truth
    Data freshness
    Domain Integrity
    Sensitive data are
    exchanged securely
    Existing
    experiences over
    different variations
    Asynchronous
    interactions over
    synchronous coupling
    Focus
    Consensus
    Official Blessing
    Why bother with your
    own principles?

    View Slide

  32. How to find your principles?

    View Slide

  33. Goals
    What’s holding us
    back today?
    What’s moving
    us forward today?
    Risks
    Strengths
    Opportunities
    Threats
    Weaknesses
    Cross-team
    relevance
    Business
    Architecture
    Requirements

    View Slide

  34. View Slide

  35. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  36. Technology Radar
    https://opensource.zalando.com/tech-radar/

    View Slide

  37. Promising, experimenting with this on one or more teams
    TRIAL
    Neal Ford, “Using the ThoughtWorks Technology Radar to track governance”
    Proven to work within this enterprise, well supported
    ADOPT
    Evaluating for potential experiments, under active research
    ASSESS
    Deprecated, don't start new projects using this
    HOLD

    View Slide

  38. Sensible Defaults

    View Slide

  39. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  40. Decision Records
    http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions

    View Slide

  41. CULTIVATING ARCHITECTURE
    How to make
    it effective?

    View Slide

  42. Autonomy
    Trust
    Voice
    Westrum
    Organizational
    Culture
    Software
    Delivery
    Performance
    Organizational
    Performance
    Forsgren et al, State of DevOps Report 2018
    https://cloudplatformonline.com/2018-state-of-devops.html
    predictive relationship
    Retrospectives
    Climate for Learning

    View Slide

  43. guide
    serve as
    deciding principle
    have decisive
    influence
    Exert a determining or
    guiding influence
    rule
    foster learning culture
    to govern
    telling people
    what to do

    View Slide

  44. Reflect & Iterate
    Talk to each other
    Record history

    View Slide

  45. “I’m ‘just’ a developer -
    what can _I_ do?”
    Captured by https://github.com/lolcommits/lolcommits

    View Slide

  46. Organization
    Unit Unit Unit
    Team Team Team Team Team Team Team Team
    Team

    View Slide

  47. Decisions
    Practices
    Business
    Architecture
    Requirements
    Principles

    View Slide

  48. CULTIVATING ARCHITECTURE
    Birgitta Böckeler @birgitta410 | Martin Fowler @martinfowler

    View Slide

  49. Resources
    ● „Who needs an architect“ http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
    ● „State of DevOps report 2018“ https://cloudplatformonline.com/2018-state-of-devops.html
    ● „Using Software Architecture Principles in Practice“ https://www.slideshare.net/EoinWoods1/using-software-architecture-
    principles-in-practice
    ● TOGAF‘s definition of Architecture Principles http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html
    ● “Using the ThoughtWorks Technology Radar to track governance” https://www.thoughtworks.com/insights/blog/using-
    thoughtworks-technology-radar-track-governance
    ● Public examples of principles
    ○ John Lewis http://engineering-principles.onejl.uk/
    ○ Scout24 https://github.com/Scout24/scout24-engineering-values-and-principles
    ○ 12 factor app https://12factor.net/
    ○ UK Government Digital Service https://www.gov.uk/guidance/government-design-principles
    ○ Zalando https://github.com/zalando/engineering-principles#zalandos-engineering-and-architecture-principles
    ● Public examples of organizational Tech Radars
    ○ AutoScout24 https://github.com/Scout24/as24-tech-radar
    ○ Zalando https://opensource.zalando.com/tech-radar/
    ○ Porsche https://medium.com/porschedev/technology-radar-vol-2-4833fb31e2fd

    View Slide