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
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
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
||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
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!
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.