Architecture is everyone's business

17-03-2023

  • url: https://uhl-steine-scherben.org/blog/posts/architecture_is_everyones_business/
  • overview
    • making architecture everyone's business
    • creating an organizational habit of active, open and transparent communication around architecture discussions (which prevents architecture drift)
    • feature owners within teams (empower engineers, make expectations explicit)
    • collaboration across teams (communities of practice, RFCs, CTO / leadership)
    • prevent technology zoos
      • create the right incentives to use boring technology to solve exciting problems
      • make it easy to do the right thing, and hard to do the wrong thing
  • shrinking importance of the software architect
    • prefer contracts over standardization
    • teams become forced to navigate rigid architecture
      • reduces degrees of freedom
      • results in weird workarounds, breakage occurs because you still need to ship features
    • dedicated and isolated architects create unhealthy team dynamics
      • influence and power struggle between architect and engineer
      • engineers try and subvert rules to push code through
    • drives unhealthy career dynamics
  • micro architecture (scoped to team)
    • feature owner
      • architecture needs to happen at the right place by the right people
        • largely happens locally
      • manager decides on feature owner
        • depth of challenge is dependent on the ticket, determine which engineer feels confident for the role
      • lifecycle
        • architecture
          • consult experts within and outside team
        • refinement
          • define user stories and acceptance criteria
        • communication
          • primary point of contact
        • delivery, rollout, handover, cleanup
        • not implementation, not deciding on final architecture (this is a team decision)
  • macro architecture (scoped to org)
    • prevent architecture drift
      • information must be public and presented in synchronous and asynchronous formats
      • needs to become an organizational habit, otherwise architecture drift
    • communities of practice
      • requires strong moderation, a senior and communication-savvy person to prepare and run these meetings
    • RFCs (request for comments) and ADRs (architecture decision records)
      • commented on, challenged and approved by a larger group of people
  • architecture north star
    • technical executive, CTO, deeply understand the business trajectory and future goals, describe the needs and demands of software
  • preventing a tech zoo
    • responsibility of executive team for guidance
    • avoid introducing every shiny piece of alpha technology
    • create the right incentives to use boring technology to solve exciting problems
    • it should be easy to do the right thing, and hard to do the wrong thing