Skip to content
  • Sign In
  • Try Now
View all events
Software Architecture

Architecture Decision Making by Example

Published by O'Reilly Media, Inc.

Intermediate content levelIntermediate

A guide for architects and developers

In this course, you’ll:

  • Use architecture decision records to make and record great decisions
  • Seek out and weigh the best advice in your decision making
  • Focus your efforts on the right decisions at the right time
  • Evolve your systems to respond rapidly to changing technical and business landscapes

Is a system’s architecture relevant if it isn’t running in production? Why do architectures so frequently get in the way of teams, slow them down, or make their lives harder when they're supposed to be helping?

Join expert Andrew Harmel-Law to learn how you can take greater control of decision making, make and take the best architectural decisions possible, and maximize your team’s autonomy and ability to flow. You’ll understand the benefits of seeking advice, discover how to maintain overall alignment and cohesion in the systems you build, and learn to embrace uncertainty while moving quickly and nimbly beyond setbacks. Through real examples and group discussions, you’ll come to grips with your everyday challenges and leave with a solid understanding of key tools and approaches that’ll allow you to get started as soon as you’re back on the job.

What you’ll learn and how you can apply it

  • Achieve true autonomy and flow in your teams by making your own architectural decisions
  • Seek challenging, even conflicting, expertise from others when making those decisions
  • Embrace uncertainty and failure, rather than weaknesses, to find the clearest route to success

This live event is for you because...

  • You’re a software developer/engineer who wants to safely exert more control over the architectures you work on.
  • You have strong opinions about bad architectures but don’t know how to go about remedying things effectively and efficiently.
  • You’re a senior or lead developer who has delivered architectures created outside your team, attempted to change the architectures your team has been tasked with delivering, or worked on a system with no explicit architecture and struggled with the result.
  • You want to become an architect without stepping away from the code and would like to get experience making architectural decisions safely.

Prerequisites

Recommended preparation:

  • Jot down the issues you have with the architecture you work with day-to-day
  • Think about the processes for making architectural decisions at your job

Recommended follow-up:

Schedule

The time frames are only estimates and may vary according to how the class is progressing.

Part I: Decision-making autonomy

Why are we here? (5 minutes)

  • Presentation: The journey ahead of you (plus some housekeeping)
  • Group discussion: Expectations for the session

Why it’s important for developers to make architectural decisions (15 minutes)

  • Presentation: Architecture running in production is the goal; autonomous teams that can flow is the ideal; how traditional architecture decision making typically prevents flow
  • Group discussion: Your experiences with autonomy and flow

Separating “architecting” from “architect” (5 minutes)

  • Presentation: Why might you be the best person to make an architectural decision?
  • Group discussion: Separating architecting from architect; What would you need in order to do this?

What is an architectural decision? (5 minutes)

  • Group discussion: What kind of things are architectural decisions?; Where can architectural decisions arise from?
  • Presentation: Things that are, or give rise to, architectural decisions

Architectural decision-making records (10 minutes)

  • Presentation: Quick intro to ADRs

Let’s make a (selfish) decision (25 minutes)

  • Presentation: Introduction to the scenario (adding release toggles)
  • Hands-on exercises: Capture your context; collate your options; think about your consequences
  • Group discussion: How is each step helping with your decision making?
  • Break

PART II: Decision-making alignment

Decision blind spots and how to combat them (20 minutes)

  • Group discussion: How might our peers feel about our selfish decision?; Who might we seek advice from?
  • Presentation: The architectural advice process (bringing in other viewpoints and the expertise of others)

Seeking and offering advice (15 minutes)

  • Presentation: Introduction to the exercise
  • Hands-on exercise: Offer advice
  • Group discussion: Evaluating and updating the ADR based on the advice received

Going meta: Advice about making and taking architectural decisions (10 minutes)

  • Group discussion: Your advice about how to make great decisions
  • Presentation: Decision-making power moves

Taking a decision and completing an ADR (15 minutes)

  • Presentation: Making the decision and completing the ADR
  • Break

PART III: Decision-making rapid learning

There are no “perfect” decisions (15 minutes)

  • Presentation: Letting go because it’s impossible to see the future
  • Group discussion: How might you get as close to “perfect” decisions as possible?

Spikes: Stop deciding, start experimenting (20 minutes)

  • Presentation: What is a spike?
  • Hands-on exercise: Draft a spike

Adoption patterns (10 minutes)

  • Presentation: How to start making better decisions tomorrow

Wrap-up and Q&A (10 minutes)

Your Instructor

  • Andrew Harmel-Law

    Andrew Harmel-Law is an overenthusiastic tech principal for Thoughtworks, where he specializes in domain-driven design, Java/JVM technologies, Agile delivery, build tools and automation, and organization design. He’s motivated by the efficient delivery of large-scale software solutions, and he understands that people, architecture, process, and tooling all have key roles to play in achieving this. His experience spans the software development lifecycle across many sectors including government, banking, and ecommerce. Andrew also has a passion for open source software and its communities, and he enjoys open-sourcing his code. He’s been involved with OSS as a user, contributor, expert group member, and paid advocate—most notably as one of the Jenkins Job DSL originators. He shares his experiences through consulting, mentoring, writing blog posts, and speaking at and organizing conferences.

    Xlinksearch