Software Architecture: Principles, Patterns & Practice · Half-day briefing or two-day workshop

Bring a real architectural decision. Leave having made it.

For senior software engineers ready to carry architectural responsibility, and for the teams that need them to.

Half-day or 2 daysBriefing or hands-on
Your own projectA live decision you bring
Online or in personHybrid available
10–25Senior engineers

The workshop

1 Principles Coupling, cohesion, reversibility – what outlasts the trends
2 Patterns Layered to event-driven, each with the context that earns it
3 Method Frame, Options, Size, Decide, Record
4 Case studies Real systems, and the decisions that held
5 Practice on your work Katas first, then the decision you brought

Your own project, from part three onward

Ends in a decision: made · reasoned · recorded

Half-day briefing: parts one to three, and one worked case. Two days: all five, katas included.

The depth behind those titles

Principles and patterns. The values good architecture serves – fitness for purpose, simplicity, evolvability, and cost honesty. The principles that outlast any trend: separation of concerns, coupling and cohesion, designing for reversibility. Then the patterns, each with the context that makes it apply.

Cases and craft. Real case studies, and the craft that keeps a living system honest. How to document architecture so the reasoning survives, using ADRs. Evolutionary architecture and fitness functions (Neal Ford and Rebecca Parsons’ idea of automated checks that guard the qualities you care about as the system changes). How delivery metrics close the feedback loop.

Judgement and kata. Architectural katas – small, timed design problems worked in groups, practice bouts for architects – build fluency. Then the real thing: the decision you brought, run through the method, coached.

Why this is different

A method, not a reading list

Frame→Options→Size→Decide→Record

Five steps you use on the case studies, on the katas, and on your own system before you leave. Most architecture teaching stops at the patterns. The decision is where the job actually is.

Patterns taught in context, not as recipes

Layered, modular monolith, microservices, event-driven – each one with the conditions that make it worth its cost, and the conditions that make it a liability.

Architecture as decisions you maintain, not a diagram you draw once

ADRs (Architecture Decision Records, Michael Nygard’s practice of writing down why, not just what), fitness functions, and delivery metrics that close the loop on what you decided.

Patterns can be read. Principles can be memorized. Judgement, knowing which applies here, is built through decisions you own.

You leave with

One real decision, made

From your own project: framed, sized, decided, and written down in a record your team can read.

A method you can reuse

You use the five steps on cases, on katas, and on your own system before you leave. They work the same on the next decision.

The map behind the patterns

Principles and patterns with the contexts that make each one apply, a working ADR habit, and kata practice.

What two days can do. Two days will not make you an architect; that is built over years. What they give you is supervised practice at the part the job demands first, on a decision that is actually yours.

How it’s taught

Cases before theory. Real systems, studied for the decisions that held and the ones that didn’t.

Katas before the real thing. Small, timed design problems build fluency in a room where being wrong costs nothing.

Led by

Samir Joshi

Systems architect, engineer, and former software engineering faculty member. Three decades building and leading production systems across India, the US, and Europe, including senior roles at Mastercard and Nokia/HERE, and long-term engagements for Fidelity and Pearson. His work now focuses on the architecture and judgement required to put AI systems into dependable production.

Attend

Run it for your team

Private · Online, in person, or hybrid

Your team's own systems and its own live decisions, under a mutually agreed NDA. Half-day briefing or the two-day hands-on.

Talk about a private workshop →

Join a public workshop

Public · Live online · 10–25 places

No public date is set yet. Register your interest and we'll tell you when one is scheduled. Enough interest is what schedules it.

Before you commit

Half a day or two days?

The half-day briefing covers the discipline and one worked case: values, principles, patterns in context, and the five-step method demonstrated end to end. It is the right size when a team needs a shared vocabulary for architectural decisions, or when leadership wants to see the method before committing to the longer format.

The two-day workshop is the full path. All three stages, katas included, ending in a coached decision on your own system with the reasoning recorded. This is the format that changes how someone works the following week.

What counts as a live architectural decision?

One that is genuinely open, that you have standing to make or to influence, and that will cost something if it goes the wrong way. Splitting a module out of a monolith. Choosing between event-driven and request-response for a subsystem that is now too chatty. Whether a build-versus-buy call on a platform component is reversible. Where an AI capability should sit relative to the system of record.

If you’re not sure yours qualifies, bring it anyway and we’ll frame it together in the first stage. Frame is step one for a reason: a good deal of architectural trouble is a decision nobody stated clearly.

Bring the decision you've been circling. Leave with it made, reasoned through, and written down.

Running it for a team? Talk about a private workshop