New Book Review: "The Software Architect Elevator"

New book review for The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise, by Gregor Hohpe, O'Reilly, 2020, reposted here:

Copy provided by Amazon.

While the title of this book makes use of the term "software architect", connotations will likely arise for many potential readers. Hohpe starts discussing the term "architect" at the outset, but it isn't until the end of chapter 4 ("Enterprise Architect or Architect in the Enterprise?") where he makes an attempt to simplify what he means with respect to this book, following his discourse on "enterprise architect(ure)". "My definition of EA also implies that some IT architects, who aren't enterprise architects, work at enterprise scope. These are largely the folks I refer to in this book. Because they are the technical folks who have learned to ride the elevator (chapter 1) to the upper floors to engage with management and business architecture, they are a critical element in any IT transformation."

"How is being an 'enterprise-scale architect' different from a 'normal' IT architect? First, everything is bigger. Many large enterprises are conglomerates of different business units and divisions, each of which can be a multibillion-dollar business and can be engaged in a different business model. As things get bigger, you will also find more legacy: businesses grow over time or through acquisitions, both of which breed legacy. This legacy isn't constrained to systems, but also to people's mindsets and ways of working. Enterprise-scale architects must therefore be able to navigate organizations (chapter 34) and complex political situations. Performing true EA is as complex and as valuable as fixing a Java concurrency bug. There's enormous complexity at all levels, but the good news is that you can use similar patterns of thinking at the different levels."

"For example, software architects need to balance their system's granularity and interdependencies: a giant monolith is rather inflexible, whereas a thousand tiny services will be difficult to manage and can incur significant communication overhead. The exact same considerations apply to business architecture when considering the size of divisions and product lines. Lastly, EA also faces the same trade-offs when having to decide which systems should be centralized, which simplifies governance but can also stifle local flexibility. Architecture, if taken seriously, provides significant value at all levels."

While I largely agree with what the author presents here, it's interesting that he includes "senior developer" in the list defining what architects are _not_ in his introduction to part 1 ("Architects"). "Developers often feel they need to become an architect as the next step in their career (and their pay grade). However, becoming an architect and a superstar engineer are two different career paths, with neither being superior to the other. Architects tend to have a broader scope, including organizational and strategic aspects, whereas engineers tend to specialize and deliver running software. Mature IT organizations understand this and offer parallel career paths." As a longtime engineer and architect who has seen and experienced a lot, I find it immensely beneficial for architects to not only have significant development experience, but have these skills close at hand.

Startups often have "senior engineers" but not "architects". During my career, I've been told by quite a few startups that they don't need architects. When I've asked them who chooses the tooling and technologies, who builds proofs of concept and prototypes, who designs their software and systems alongside other stakeholders, and who provides governance, they often draw a blank. In exploring their responses to me, it becomes clear that either (1) their senior engineers act as architects, or (2) their software and systems are already in production, and they are in maintenance or some other mode. The challenge with the former is that senior engineers often don't see the big picture, and the challenge with the latter is that software and systems should arguably be built as products, which means continued evolution should be expected to take place over time.

This book is presented in 6 parts: part 1 ("Architects"), part 2 ("Architecture"), part 3 ("Communication"), part 4 ("Organizations"), part 5 ("Transformation"), and part 6 ("Epilogue: Architecting IT Transformation"). Despite my prior comments, I think the ongoing industry discussion on the role of architects is desperately needed. I've read and written a lot on this topic over the years, so I especially appreciate the subtitle to this book: "Redefining the Architect's Role in the Digital Enterprise". As with software and systems products, architects should also evolve. The challenge here is that there simply aren't any industry standard definitions for many terms commonly used in industry, and this text provides a great effort at attempting to sort everything out. Much like the term "strategy", which I've also read and written a lot about, the second part on architecture follows closely behind the discussion on architects. And in my view, the topics discussed in the third part are the bulk of what tends to shy away some senior engineers from identifying as architects, as I have personally seen a lot of paper pushing architects in the past. As the book progresses into the last two parts, the chapters increasingly resemble disjointed, separately publishable articles, although the author makes a good attempt at tying everything together.

Hohpe actually mentioned when this book was headed to the printer that it is admittedly an evolution of the "37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey". At the time, he also stated that the term "software" snuck into the title because he edited the book to appeal to a broader audience of not just enterprise architects, but software architects looking for their next career step. All of this said, this work helps fill a large gap that has existed for many years, and I highly recommend it. While much of what this book presents will be common knowledge to longtime architects, especially those who have worked as consultants in both senior engineer and other leadership roles, what has largely been tribal knowledge is now arguably under one roof. Of course, not to be forgotten is that Hohpe brings his personal experience along for the ride, and as with any great book of this genre, execution eats strategy for lunch.