Books
Fundamentals of Software Architecture by Mark Richards and Neal Ford
Start here if you’re an engineer moving toward architecture. It covers architecture characteristics, component thinking, and the major styles like layered, microkernel, event-driven, and microservices. The breadth is the point; it’s a map of the territory rather than a manual for any one destination, so don’t expect it to settle the decision in front of you.
Software Architecture: The Hard Parts by Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani
The sequel, and it assumes you already have the fundamentals. The subject is distributed systems trade-offs like service granularity, pulling data apart, distributed transactions, and contracts. What makes it useful is that it refuses to hand you answers, working instead through trade-off analyses that show what each choice costs you. Read it when you’re facing a decomposition decision, not before.
The Software Architect Elevator by Gregor Hohpe
Architecture rarely gets taught as an organizational skill, and this book treats it as one. Hohpe’s premise is that the architect’s job is riding between the executive floor and the engine room, translating in both directions. If your technical judgment is sound but your recommendations keep dying in rooms you aren’t in, this covers what’s missing.
Sites and Newsletters
Utley ran Stanford’s d.school and now writes and speaks on AI adoption and creative practice. His central argument is that teams should treat AI as a teammate they coach rather than a tool they operate, and that the gap between what AI can do and what most organizations get from it is a behavior problem rather than a technical one. Start with the Beyond the Prompt podcast or the Methods of the Masters newsletter, and read Ideaflow if the thinking lands.
Two decades of patterns and essays that haven’t aged much. Fowler publishes when he has something to say rather than on a schedule, so the archive rewards browsing more than the feed rewards subscribing.
Mark Richards’ free video lessons, each narrow enough to watch over lunch. A good companion to the two Richards and Ford books if you’d rather be talked through a topic than read it.
Paid .NET and software engineering courses, taught by practitioners rather than career instructors.
A quarterly assessment of what’s emerging, what’s proven, and what to stop using. The “hold” ring is the part I read first, since almost nobody else publishes what they’d walk away from.
News and deep dives, with a good hit rate on conference talk writeups that save you the hour of video.
Cloud patterns from the people who operate the services, which beats the secondhand version.
Framework creators document their own tools better than third-party instructors do. When I need to learn a .NET feature, this is the first stop and usually the only one.