I offer training classes for organizations who would like a deeper dive into the content I've written and spoken about over the years.
All of my classes are hands-on, with supporting exercises to help turn abstract concepts into concrete results. I also encourage digressions that allow me to apply my years of consulting experience to apply the lessons within a familiar context.
The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren’t there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it’s a fast moving discipline, where entire suites of best practices become obsolete overnight. This workshop provides a foundation to build upon to start the journey towards software architect. I offer two different versions of this workshop based on length, either two or three day.
This workshop focuses on the foundational material required for success as a modern software architecture. It touches upon the major design elements of the role and discusses several soft skills such as communication as well.
Each section includes group-based, hands-on exercises to help make abstract architecture concepts
Agentic AI shows new possibilities in software architecture, including the ability to work towards a solution as long as deterministic constraints exist. Suddenly, developers and architects are trying to build ways for agents to determine success, which requires a deterministic method of defining these important constraints: Architecture as Code.
An increasingly common practice in agentic AI is separating foundational constraints from desired behavior. This class shows how to use the concepts in Architecture as Code to help build foundational constraints to help guide agents to build properly architected code.
We have been thinking about this problem for several years, even before agents. How is that? A funny thing happened on the way to writing our book Architecture as Code–the entire industry shifted. Generally, we write books iteratively–starting with a seed of an idea, then developing it through workshops, conference presentations, online classes, and so on. That's exactly what we did about a year ago with our Architecture as Code book. We started with the concept of describing all the ways that software architecture intersects with other parts of the software development ecosystem: data, engineering practices, team topologies, and more–nine in total–in code, as a way of creating a fast feedback loop for architects to react to changes in architecture. In other words, we're documenting the architecture through code, defining the structure and constraints we want to guide the implementation through.
Created: 2026-03-16 Mon 10:59
Why do authors write technical books about topics like software architecture? They write them when then have figured something out, a "best practice" that is general enough and has matured enough to tell the rest of the world. In fact, architects rely on the current (but always shifting) notion of "best practices" for guidance in solving tough problems.
But what happens where there are no best practices? What if no one has ever solved this particular problem before? What if there are no good answers, just varying degrees of awfulness?
When you're a software developer, you build outstanding skills in searching online for solutions to your current problem. For example, if you need to figure out how to configure a particular tool in your environment, expert use of Google finds the answer.
But that's not true for architects.
For architects, many problems present unique challenges because they conflate the exact environment and circumstances of your organization--what are the chances that someone has encountered exactly this scenario and blogged it or posted it on Stack Overflow?
When architects encounter novel problems (by the way, they're all novel when you become an architect), how do they make decisions if no "best practices" exist and no one has ever solved this problem before?
The real job of an architect is, when presented with a novel situation, how well can they delineate and understand the tradeoffs on either side of the decision, so that the organization can make the best informed decision.
The material represents both the source and derivative of the book Software Architecture: The Hard Parts: the authors conducted workshops and training classes for several years, refining the material and the narrative, distilling the difficult problems facing modern architects. Because each software architecture is unique, generic advice doesn't help (which is why not many advanced software architecture books exist). However, every architect can benefit from learning how to perform trade-off analysis, which is what this material does, using common problems in microservices architectures.
Each workshop features both exposition and hands-on, group-based (for in-person classes) exercises to apply the concepts to realistic scenarios.
