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.

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