Thinking Architecturally

Preface

Rich Hickey once said programmers know the benefits of everything and the tradeoffs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. But as an architect you must consider the tradeoffs of every new library, language, pattern, or approach and quickly make decisions often with incomplete information. How should you think about the inevitable technology choices you have to make on a project? How do you balance competing agendas? How do you keep your team happy and excited without chasing every new technology trend?

As an architect it is your responsibility to effectively guide your teams on their technology journey. In the following report, you will follow the arc from discovering a new technology through to maintaining technologies in your organization. You will learn the importance of tradeoffs, how you can analyze new technologies, and how you can effectively capture the inevitable architectural decisions you will make. You will also explore the value of fitness functions as a way to ensure the choices you make are actually reflected in the code base.

Before you read any further, I want to clarify a point about titles. In the software industry, titles aren’t very well defined. Ask 20 developers to define architect and you will get at least 20 different answers. There are more than a few organizations that proudly say they don’t have architects! Additionally, the title of “architect” can be closely guarded in some organizations.¹ As much as some people make very fine-grained distinctions, I hope people without architect in their title give this book a read and find something useful in it. As such, it is meant for tech leads, senior developers, junior developers, and of course, practicing architects, regardless of actual titles.

Whatever your title, you won’t become an architect through words alone. You need an opportunity to practice the skills successful architects possess. That is why every chapter has a set of Katas, or exercises, to help you master the concepts. Katas originated in martial arts training, but the idea has spread beyond the dojo. As Fred Brooks famously said, “How do we get great designers? Great designers design, of course.” This, of course, implies that the way to get great architects is to, well, architect a great system!

However, the average architect may only work on a small handful of applications. How are you supposed to become a master without the needed practice? Professional athletes spend far more time practicing their sport than they do playing in games that “count.” Professional musicians and actors spend countless hours rehearsing before performing in front of a live audience. But beyond a perfunctory class, most architects learn on the job, meaning they make their mistakes on live projects. Is it any wonder so many software projects fail to deliver the expected value?

The concept of architectural katas arose from a series of workshops that Ted Neward, Neal Ford, Mark Richards, Matt Stine, Simon Brown, myself, and a few others have led over the last several years with the goal of giving participants an opportunity to work through a pseudo real-world problem and its architectural issues.

With that context, each chapter will present you with opportunities for effortful study. But you should also familiarize yourself with the Architectural Katas and what it takes to lead your own.

Acknowledgments

First and foremost, I want to thank my wife Christine for her constant support on my ever evolving journey. I could not do what I do without her in my corner. On more than one occasion she has shouldered more than her fair share so that I could present at some conference, teach a class, or write a book. To my son Everett for tolerating my sometimes erratic schedule and always welcoming me home with a giant smile and a hug. Even when I’m not home, I’m always thinking about you Ev! I lack the words to properly express my gratitude for my amazing family.

The team at O’Reilly Media is amazing and I appreciate their patience and guidance throughout the process of writing this report. Many thanks to Brian Foster for molding my thoughts into a more coherent narrative, to Alicia Young for turning my writing into something readable and to Nick Adams and Christina Edwards for shepherding me through the production process. If you’d have told me twenty years ago I would be part of the O’Reilly family I would never have believed it possible. Thank you to everyone that has welcomed me as a speaker, as a teacher, and as a writer.

I am where I am today thanks to an amazing group of people I am privileged to call my friends. To paraphrase Isaac Newtown, I have had the great fortune of standing on the shoulders of giants and I want to extend my heartfelt appreciation to those that have shaped my thinking on everything from software to fine dining to slinging slides. To Martin Fowler, Brian Goetz, Neal Ford, Matthew McCullough, Stuart Halloway, Justin Gehtland, Ken Sipe, Scott Davis, Mark Richards, Tim Berglund, Craig Walls, Venkat Subramaniam, Matt Stine, Glen Vanderburg, Dave Hussman, Ken Kousen, Mike Nygard, Kirk Knoernschild, Christopher Judd, Daniel Hinojosa, Raju Gandhi, Jeremy Deane, Peter Bell, Howard Lewis Ship, Pratik Patel, Brian Sletten, Michael Carducci, Danny Brian, Ted Neward, Joe Athman, and Aaron Bedra, I still don’t know what I did to warrant such an amazing group of friends. The next round is on me! Assuming you read this. I also want to thank the many talented architects I’ve had the privilege to work with over the years. From Gary Gillard, my “first” architect on the first web project I was a part of to Jeff Escott for teaching me many of the subtler aspects of the job to my good friend Aasta Frascati-Robinson for being such an inspiration. Mark Stofferahn shaped my thinking on so many things from quality attributes to the cloud. Karim HadjSalem and Matt Gorman were quick to remind me sometimes the only option is to laugh it off. To Scott Leigner, Bob Baty, Cam Sonido, Steve Shaw, Rick Meemken, Dave Dahl, Mike Gitberg, Mike Samra, James Brown, Rob Harwood, Craig Gronlund, Hoa Ton-That, Pee T Lim, Ken Lamb, Don Smith, Eamonn Buss, Chad Hinkel, Chris Lyons, Raina Johnson, Joe Drechsel, Bobby Kaminsky, Ted Setterlund, Mark Schreifels, Bob Casola, Jim Payant, and Jill Spear, thank you all for your advice, your wisdom and your friendship. And to anyone I omitted from this list, my humblest apologies, know that it was a simple off by one error on my part and not a deliberate slight.

¹ I was a “senior developer” doing architecture work for years before I finally was officially named an architect.