Practical Software Architecture for AI (And Everything Else)

$1,295.00

10/7–10/9, 2024, 9:00AM-12:00PM US Pacific Time

Coding skills alone are not enough to get or keep a job in an AI world, no matter how good you are. In this class, you’ll learn the architectural skills and systems thinking you need to use AI in a way that yields a scalable and extensible system.

11 slots remaining

SKU: incr-arch-07-24-1 Categories: ,

Practical Software Architecture for AI

(And Everything Else!)

Coding skills alone are not enough to get or keep a job in an AI world, no matter how good you are. In this class, you’ll learn the architectural skills and systems thinking you need to use AI in a way that yields a scalable and extensible system. Architecture is a core technical skill, maybe more so than coding—essential if you want to stay relevant, whether or not AI is on the scene. You’ll walk away from this class with those skills.

A perfect implementation of an inappropriate architecture is a liability. You’ll learn to create effective architectures that make your system easy (and less expensive) to build, maintain, and scale, whether or not an AI helps with the coding. You’ll learn how architecture impacts how you work, touching everything from process to organizational and team structure. A team can’t work effectively when it fights the architecture to make small changes, and agility becomes impossible.

There isn’t an LLM on the planet that understands architecture. An LLM can code, but it can’t design, because design requires judgment. Without your help, the AI produces a bag of unmaintainable goo that “drifts” gradually into systems riddled with mysterious bugs that can’t scale or adapt easily to new requirements. You can’t just specify features in your prompt and hope for the best; you must tell the LLM how to build those features in the context of a specific architecture. In this class, you’ll learn about practical architectural approaches that can rein in the chaos and reduce AI-assisted modification and debugging costs by an order of magnitude.

There is no one-size-fits-all “best” architecture, however. An architecture that’s appropriate in one context works against you in another. You’ll learn several architectural approaches in this class and how to combine them to create an optimal architecture for the problem at hand. Architecture is all about informed trade-offs, and this class shows you how to make them.

In this class, you’ll learn how to:

  • Create effective software architectures for your products and systems, whether or not AI is involved

  • Create architectures that welcome changing requirements and facilitate teamwork without adding dependencies that can slow you down

  • Design systems that support AI-assisted software engineering, make it easy to incorporate the code the LLM writes, manage contexts effectively to improve accuracy and keep token costs down, and limit the blast radius when the LLM makes a mistake

  • Acquire a palette of architectural approaches and patterns that help organize your thinking.

  • Make effective architectural trade-offs

  • Design systems that can evolve incrementally over time. Incremental architectures start simple, and grow as you learn as the need for scaling emerges

  • Design “Agentic” (LLM-based) software systems based on modern component architectures (agents, microservices, components-in-a-monolith, etc.)

  • Design systems that work well in distributed or cloud environments, are highly reliable, secure, and fault-tolerant.

  • Build effective APIs for both human and intelligent agent-to-agent communication

  • Design domain-focused event-based systems using DDD and event storming (particularly well-suited to rapidly changing requirements and discoveries made in tight customer-feedback loops)

Outline

What is architecture?

Implementation independence

The role of the Architect

Architectural and systems thinking

AI-appropriate architecture

Addressing AI drift

Components and context management

Taming the AI assistant

Adding architectural skills to Claude

Incremental product development and architecture

Last responsible moment (decisions not made)

Integrating coding and product development

The inspect-and-adapt loop.

Architectural coherence when developing incrementally

Architectural decision records (ADRs)

Working with architectural patterns

Systems of interlocking patterns

Managing trade-offs

Architectural characteristics

Defining -ilities

Structural architecture

Conway’s Law

Entities, aggregates, agents

Dependencies

Cyclic and acyclic dependencies

Stability and volatility

Dependency inversion

Layered architecture

N-tier

Sinkholes

Abstraction Layers (hardware, OS)

Hexagonal (port and adapter) architecture

Open-closed principle

Interface segregation

Layering

Port-and-adapter messaging

Dataflow across boundaries

Distributed architecture

Deutch’s Fallacies of Distributed Computing

Inter-service communication

Brokers and proxies

Logging, monitoring, and observability

Story-focused architecture

What is a story?

Thin vertical slices

Stories vs. use cases

Story-driven decoupling

Services

WET and DRY

Discovered, not invented

Problem statements

The 4 C’s:

Communication, collaboration, confirmation, and “cards”

Strategic planning, not estimating

Responsibility-driven design

Single-responsibility, Common closure

Interface segregation, Common reuse

CRC: Class, responsibilities, collaborators

Nested responsibilities and Story Agents

API design for orchestrated systems

REST APIs

Error recovery

Idempotency

Workflow analysis

Narrowing stories

Converting stories to a domain model

Design by Coding: deriving declarative APIs from stories

Component architectures and microservices

Testability

GUI, logic separation

Components and AI contexts

Opaque components, impermeable boundaries

Liskov substitution

Data (and database) encapsulation

Fault tolerance: circuit breakers and bulkheads

Microservice characteristics that differ from other components.

Agents

Presentation, abstraction, control

Micro front ends

Domain-Focused Architecture

Event-driven (messaging) architecture

Choreographed vs orchestrated systems

Proxies and brokers

Queues and publish/subscribe

Event payloads

User, transaction, and request IDs

Lightweight messaging systems

ZeroMQ (brokerless)

Kafka (brokered)

REST-to-messaging portals

Transaction management

Error detection and recovery

Self-scaling systems

Naming services

Lambdas

Domain-driven design

Event storming

Converting the event model to a static model for implementation

Implementation traps & pitfalls

Agentic AI Architecture

Adding “intelligence”

Micro-agents and macro-agents

LLM integration

Talking to LLMs through public interfaces

The model context protocol

Local vs Cloud LLMs

Selecting a model

Ollama, Pydantic, and Docker

Orchestration and the judge

Security

Risks and guardrails

Data vulnerabilities

The LLM doesn’t understand configuration

Prompt injection

RAG and accessing local databases

Allen Holub

Allen Holub

Allen Holub has been writing software since dinosaurs roamed the earth, starting in high school on an IBM 360/65 enthroned in a glass-walled temple and fed punch cards by white-clad priests. Since then, he’s written two operating systems and several compilers and contributed to several commercial and open-source products, all without punch cards. He’s been a CTO for early-stage startups and a Principal Architect for a medium-sized one. He’s authored a gazillion articles and a dozen books, some used as texts at U.C. Berkeley, MIT, Cal Tech, and IIT. He was a contributing editor at Dr. Dobb’s Journal and JavaWorld.

Allen speaks internationally, consults, and teaches practical software development processes and software architecture. He has been an independent consultant for decades, helping hundreds of clients become highly effective (faster, better, delivering sooner) at creating products that customers love. Allen works with all levels of the organization, from the CEO to sitting down and mobbing with the teams. He was the Chan-Norris Distinguished (no less) Professor of Computer Science at Mills College.

Allen plays the piano, rides a bicycle, and flies small airplanes, but not at the same time.