The Architect’s Penthouse Bookshelf

Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.

When you hitchhike through the galaxy, a towel will generally do. To ride the Architect Elevator you need to be a bit better equipped. Riding the elevator up and down is exciting and provides tremendous value to the organization. But it is also demanding as the architect needs to adjust to different audiences, backgrounds and dynamics, becoming a technology shapeshifter of sorts. To help with this transformation (and to avoid getting your rear kicked by Leela), I recommended a few books for each major section of the corporate high-rise.

I should clarify that in this context I interpret “Enterprise Architect" as any IT architect who works in a large enterprises, covering a broad scope of responsibilities. This can be a strategic architect, but also an infrastructure or data architect. Specifically, I don't limit it to prototypical “Enterprise Architects" that manage application inventories, conduct gap analyses, and devise transformational roadmaps. I could have called the role "Architect in the Enterprise" to make the distinction clear, but that's not as catchy.

You won’t find any computer technology books on this list. I assume architects looking to play a technical leadership role already have the technical foundation to do their job and the inclination and drive to keep learning new technologies. This bookshelf is about becoming a better thinker and decision maker and about engaging with upper management in meaningful ways.

37 Things One Architect Knows

This list originated from audience requests for the slides from my talk The Enterprise Architect - Ivory Tower Resident or Corporate Savior?. It does not aim for completeness and is subject to the serendipity of me discovering some great books while completely missing other equally great books. As mentioned in my disclosure, I earn a referral fee through the Amazon Associates program for any books you purchase through the links in this blog post. It’s certainly not enough, though, to make me recommend books just to earn a fee. I have purchased all the books I list, except where explicitly mentioned (my reading bandwidth is limited).

I would also not want to miss the opportunity to test interest in my book side-project 37 Things One Architect Knows on LeanPub. Right now it’s just a skeleton, but please give me feedback to your level of interest in acquiring the content as a DRM-free lean pub (or print) book. The content is an organized, edited, and expanded version of some of my Ramblings.

Navigating the Penthouse

Let’s start riding the architect elevator from the top floor – the penthouse. Successful interaction in the penthouse depends on a combination of factors:

• You need to have a solid read on the company strategy and major industry trends.
• You must be able to get your point across to a largely non-technical audience.
• You have to be able to get support for your ideas and projects.

Knowing What’s Going On

Feeding my inclination to include popular culture analogies, this section header reminds me of the epic movie Metropolis by Fritz Lang. The city of Metropolis is likely the ultimate example of an organization that maintains a strict separation between the ruling class in the penthouse (enjoying themselves in the “eternal gardens") and the workers toiling deep underground in the engine room. The ruler’s son Freder is not an architect, but he does end up saving the whole place from self-destruction by riding the elevator up and down after trading places with a worker in the machine room. In the end he becomes the much needed mediator between the “head" and the “hands" in something you might call an enterprise transformation. To top off the metaphor, the 1984 version of the movie by Giorgio Moroder contains a song titled “What’s going on?" by Adam Ant. Knowing what’s going on is critical if you want to engage in the penthouse.

I often tell people that you will encounter much fewer surprises in your professional life if you can think like your boss’s boss. In corporate IT, this typically translates into tracking Gartner, Forrester, IDC and other analyst firms. Hard-core technologists may despise some of this material because analysts have a tendency to invent buzzwords for already existing trends that plant dangerous ideas into pointy-haired management’s heads. If that’s how you feel, consider following the analysts like listening to enemy radio: you may not agree with what is being said, but you are better informed and prepared.

A successful architect also needs to understand what drives the business. After all, the architect's job is to build IT platforms and systems that support the business. For example, if you work in insurance you need to understand the impact a low-interest environment has on the life insurance business. You also need to understand the critical use cases for major technological advances like the Internet of Things (IoT) in your industry. Which publications or books to read for this aspect will depend on the business you or rather your employer is in. Try having coffee with business people more often!

The first two book recommendations cover major trends that upper management should pay attention to, so these are not only books you should read but also books you should recommend to your management to read. I have been handing out many copies of these in our organization.

	The classic “novel" behind DevOps and already fairly widely known (over 1000 reviews on Amazon) is The Phoenix Project, a healthy mix of getting IT operations out of being the perceived bottleneck who gets kicked by application development and the business, “system of constraints" thinking a la The Goal and IT-enabled business transformation, all wrapped into a highly readable storyline with actual characters, including the IT ops whiz-kid who can do everything but explain nothing, the security officer who is bringing everything to a grinding halt, and the change manager who is mired in bureaucratic processes. The storyline including the dramatic low-point (our hero quits) and the happy ending (not telling) reminds us of the recipes described in some of the books on storytelling below. While a “must-read" for everyone involved in corporate IT, I don't find the text terribly actionable. You may hand it out as an awareness builder and to collect some brownie points for seeing the changing role of IT in large organizations. I have not yet read the The Visible Ops Handbook by the same authors, which promises to be more concrete and actionable.
	A great follow-on read to The Phoenix Project is Jeff Sussna’s recent book Designing Delivery. While the title may mislead (physical) book stores into shelving the book under “expecting mothers", I found this book to do the best job so far at explaining how traditional IT has to change in order to survive in the digital world when the business is ready to replace the slow and unreliable IT with Amazon cloud solutions. Jeff explains well that DevOps is not (just) about sitting developers and operations staff together, but that it is based on a fundamentally different model, which derives from cybernetic systems, complex systems, and design thinking. It is noticeable that the book is composed of three distinct trains of thought, but I don’t see that as an issue – just read the parts that are most useful for your situation. After having had the chance to meet Jeff in person, I handed a copy of the book to all our business unit chief architects.
	While the first two books focus on operational aspects of IT, i.e. building a bridge to the “engine room", I’d also throw in one book on traditional enterprise architecture. Probably not the best overall book on the topic, but a definite classic is Enterprise Architecture as Strategy by MIT’s Center for Information Systems Research master minds Jeanne Ross and Peter Weill. This is a book about IT, not an IT book. It’s also a bit dated (anno 2006), but some of the graphics have become classic (most of them are visible on the CISR Enterprise Architecture Site). Here you can learn how company leadership thinks about the role and the state of their IT. Good to know if you are part of said IT.
	No list about understanding the changing role of corporate IT would be complete without Eric Riese's The Lean Startup, which has made "Minimum Viable Product" and the "Build - Measure - Learn loop" household terms alongside "Agile" and "DevOps". The core idea to maximize the amount of learning by validating assumptions by placing actual products in front of your customer is as simple as it is profound. As with most simple ideas, though, implementing them can be harder than it may seem: you need to be fast, smart, and close to the customer. Large corporations that "test" their ideas on the white board and hire armies of external consultants to build solutions have a long way to go towards this vision. Getting the idea in front of as many people as possible is still the best way to start changing the way the organization works.

Making Your Point

Understanding industry trends and getting attention are great, but only if you have a point to make and are able to get it across. This requires more than just pretty slides and a wide stance - you also need to have a compelling storyline and stir your audience's emotions. Architects and engineers too often believe that because they have analyzed the situation and found the best path of action that everyone with a reasonable IQ would have no choice but agree with them. Sadly, this is one of the biggest fallacies of technically-minded presenters -- over 2000 years ago Aristotle already knew that you can argue based on logic (logos), but also on the character and credentials of the presenter (ethos), or based on emotion (pathos). That fact that he ordered them as ethos, pathos, and logos should make rational thinkers think again.

When you are using logos, i.e. logic to reason about technical matters, never forget to build a ramp for your audience - otherwise they can't even appreciate your logos. Tons of books describe how to make expressive slides and give convincing talks, so I’ll just highlight lesser known titles specifically aimed at technical writers and presenters.

	Stories that Move Mountains is not your usual book -- it feels more like a collage of ideas and anecdotes from three Microsofties. So you better have a look inside before buying it to see whether the format suits you. I found the "noisy" visual style a bit distracting -- it's certainly no book you can read back-to-back. But the techniques are very useful when crafting engaging storylines to multiple levels of audiences. We learn about how to setup a plot (yes, something else to learn from Aristotle) and behind all the colors and fonts we learn a fairly structured process consisting of Content (Why, What, How, What If), Audience, Story (Structure, Character, Sense of Urgency, Plan), and Tell, the last one being related to delivering the story, but named to generate the backronym CAST. If you are worried that following such a simple "recipe" will appear repetitive, just look at all the Hollywood movies that rake in hundreds of millions of Dollars with seemingly even simpler recipes. People like to be entertained. Even at work.
	When it comes to making pretty slides and impressive stage performances, it's one of the rare times when you can trust the consultants. In this book, "the consultants" have taken a fresh approach of teaching presentation design and delivery by using Presentation Patterns, which has the advantage of giving you a “menu" of presentation techniques as opposed to the “one right way" of a wide stance and deep breath. The patterns also have catchy names like "Carnegie Hall" (practice, practice, practice) or "Crucible" (the best way to improve your presentation is to give it). The content covers coming up with a storyline ("Narrative Arc"), creating the slide material (the authors may be a bit heavy on using animations), and delivering the presentation. Patterns related to visual effects include detailed instructions on how to implement them in popular tools like Keynote and PowerPoint. Coincidentally, I contributed the somewhat obscure PowerPoint menu option to get the Charred Trail pattern to work properly.
	Richard Guindon pointed out that writing is nature's way of telling us how sloppy our thinking is. That alone makes writing a worthwhile exercise as it requires us to sort out our thoughts so we can put them into a somewhat cohesive storyline. Unlike most slide decks well-written documents are also self-contained, so they can be widely distributed. The curse of writing is, though, that interesting topics are hardly ever linear, but writing is: word after word, paragraph after paragraph. I described before how you can help the reader break out of this linearity, but this doesn’t put away with the need to string together words and sentences into a single, meaningful sequence. To computer scientists writing could hence be portrayed as a graph traversal problem: how do you walk the topic graph or mind map so that the resulting path is easiest for the reader to follow? The book The Pyramid Principle presents such an algorithm of traversing a topic hierarchy (called “pyramid" in the book). The McKinsey staple "Situation - Complication - Solution" that is also covered in the book (the author is a former "Mackie") makes for a very simple, but effective storyline. That is, unless you turn these concepts into actual chapter headings, which one of our McK consultants insisted on doing. Oddly, the title seems out of print in some markets and appears in many different editions and versions at occasionally mind-boggling prices. The author is now selling an expanded textbook for a whopping US$ 135! I recommend you look for a good used copy on Amazon - they start at US$ 40.
	Some 95% of the world's population are non-native speakers of English (some British fellows may even petition to exclude the 4% across the pond from that set). Hence, in my rambling on Writing for Busy People I introduced the book Technical Writing and Professional Communication for Non-native Speakers. Sadly, it's also out of print, which is especially surprising in light of its 92% "5 star" reviews (plus a single 4-star review). The chapters on "General Strategies for the Writing Process" are a great intro (just skip the chapter on "Using the Computer" - the original title dates back to 1983), but the real asset are the chapters under "Readability". They contain the best guidance on how to cover complex technical topics that I have seen: not only do we learn how to structure lists ("parallelism") and paragraphs ("chronological", "cause-effect", "comparison", etc.), but also how to maintain focus through "optimal ordering of noun phrases." I'd posit that many a native speaker / writer could benefit significantly from this guidance. This book is all about logos: examples from arcane technical domains like financial derivatives or chemical processing plants highlight how proper transitions between sentences can help the reader follow the technical logic. This book convinced me that English grammar is very suitable for describing complex technical relationships in simple words and clear structures. Take advantage of that! Despite its age I still recommend it to anyone doing technical writing on complex subjects. I often say that we must minimize the percentage of brain cells the readers must use to parse the sentences and paragraphs, so that they have more brain cells left for your content!

Gathering Support

Now you understand the business strategy and the role architecture plays in it and you have attracted management’s attention with a killer presentation. Now you need to get support for your ideas! And the support doesn’t necessarily come from the person highest in the org chart. Better yet, you have done your homework before and aligned with key stakeholders and influencers. To understand how organizations work and how to navigate them, a few more books are helpful:

	The book The Ape in the Corner Office was recommended to me by Erik Meijer. Even though I have not had a chance to read it, I blindly trust Erik’s advice and his verbal summary. The long story short is that despite all noble thoughts and thousands of years of evolution, when you put a bunch of humans into a social structure, the dynamics are awfully similar to putting a few primates into a cage: individuals fights for position, split into groups, take up habits (or corporate culture). The somewhat cynic, but quite accurate revelation is that in large organizations only two motivators dominate decisions making and behavior: fear and greed. Bringing your message to this level might make you feel a tiny bit dirty, but it’s bound to get your point across.
	If you want to get support from your audience, you first need to understand how people think, or rather how our brain works. The most popular and quite arguably the best title on that subject is Danny Kahneman's Thinking, Fast and Slow. As so often, the premise is simple: we have two types of modes in our brains, one that works fast and automatic, but can play tricks on us, and another one that is much better, but that requires conscious effort to gear up. This insight isn't completely new, but Kahneman focuses on the interplay between the systems and provides great examples and stories on how to use this insight when presenting or receiving data. On top of all that it's an entertaining read and a great source of anecdotes: I have used the "Kidney Cancer" example in my talks because it illustrates so easily how our mind plays tricks on us.
	I have to admit that the first time I heard about Dale Carnegie's How to Win Friends and Influence People I was a little put off by the title as it sounded pretty insincere to me. Having found out much later that Carnegie actually changed the spelling of his name (originally "Carnagey")to coincide with Andrew Carnegie, who built the aforementioned hall, to gather more attention all but underlines my initial impression. The book is of course coming from an American cultural point-of-view, which will make some Europeans, who still struggle to internalize that "how are you doing today?" is actually not a question, scratch their heads. On the other hand, the book that pretty much started the market for self-help books in the US and has sold over 15 million copies is certainly worth a read. And some of the advice like "be genuinely interested in other people" does sound a bit more sincere than the title. If you are impatient, the Wikipedia page summarizes the key points.

If you feel like reading these books will make you a better shrink but not a better IT architect, recall that you are preparing for visits to the penthouse. Enjoy the read and the ride.