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.

645147e9899005bc24e5ff7d65a1d60c?s=128

Birgitta Boeckeler

May 09, 2019
Tweet

Transcript

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

  2. CULTIVATING ARCHITECTURE What?

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

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

    that is
  5. CULTIVATING ARCHITECTURE Why?

  6. Cumulative features Time No / Poor Architecture Good Architecture

  7. CULTIVATING ARCHITECTURE

  8. https://agilemanifesto.org/

  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
  10. “We need some governance”

  11. manipulate control rule restrain guide serve as deciding principle have

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

    determining or guiding influence rule to govern
  13. Business Architecture Requirements Decisions Practices Principles

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

    Team Team Team
  15. Decisions Practices Business Architecture Requirements Principles

  16. Push & pull the business context

  17. None
  18. Decisions Practices Business Architecture Requirements Principles

  19. Architecture Requirements

  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
  21. Prioritise Offline Availability Portability Data privacy … …

  22. Decisions Practices Business Architecture Requirements Principles

  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
  24. Statement Team Decisions System Qualities Team Decisions Team Decisions Team

    Decisions guide lead to Require- ments
  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.”
  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
  27. http://engineering-principles.onejl.uk

  28. Sam Newman, “Building Microservices” Rationale Implications

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

    X Customer centricity
  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
  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?
  32. How to find your principles?

  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
  34. None
  35. Decisions Practices Business Architecture Requirements Principles

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

  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
  38. Sensible Defaults

  39. Decisions Practices Business Architecture Requirements Principles

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

  41. CULTIVATING ARCHITECTURE How to make it effective?

  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
  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
  44. Reflect & Iterate Talk to each other Record history

  45. “I’m ‘just’ a developer - what can _I_ do?” Captured

    by https://github.com/lolcommits/lolcommits
  46. Organization Unit Unit Unit Team Team Team Team Team Team

    Team Team Team
  47. Decisions Practices Business Architecture Requirements Principles

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

  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