Book 37 Things One Architect Knows About IT Transformation

At the beginning of the year, I read the book 37 Things One Architect Knows About IT Transformation and as time progresses, I’m increasingly realizing how excellent it is. The book describes who an architect is and what their tasks are. It explains how relationships and communication work within organizations and emphasizes patterns and anti-patterns in them. It’s definitely worth reading and I assume I’ll return to it several more times. I’d like to summarize a few insights that caught my attention the most.

Architecture is about documenting and explaining decisions

An architect’s goal should be to comprehensibly document and explain architectural decisions. If they’ve done their job well, the context that led to these decisions should be clear even years later. Subsequently, it’s possible to look at these decisions through the lens of current requirements and evaluate their relevance.

Every system tries to solve the problem it was designed for

A system needs to be viewed with awareness of what problems it was designed to solve and what technological possibilities existed at the time of implementation. For example, a steam locomotive is apparently an excellent solution to a certain problem, even though it’s outdated today.

Systems resist change

Systems tend to resist change, and it doesn’t matter whether it’s a moving car you’re trying to stop or a department where you’re trying to implement process changes.

When you don’t kill anything, you’ll live among zombies

Sometimes the right decision is to kill a system. If you support everything you’ve ever created indefinitely while simultaneously adding new components, you’ll eventually end up among a pile of zombies who will have a great appetite for your brain.

When it hurts, do it more often

If you have problems with some process, do it as frequently as possible. It will force you to change it so that the suffering is less.

Never send a human to do a machine’s job

People make mistakes, so automate all possible work. Automated and repeatable operations increase confidence in the solution.

Control is an illusion

You need to come to terms with the fact that you don’t have control over many things. Rather, it makes sense to focus on being able to solve potential problems as effectively as possible. Looking for ways and processes to have everything under control with the vision that problems won’t appear afterward doesn’t work.

Explicit knowledge is correct knowledge

If some knowledge is only in your head, it’s more of a secret than knowledge. Document and share.

Think like developers

Use version control, pipelines, automated quality checks, even when you’re not writing code and whenever it’s even slightly possible.

Black markets are not efficient

A black market forms where it’s complicated or impossible to get what you need. If your company works this way, you have a big problem. New market participants can’t navigate it and must discover the contacts and rules of the black market themselves.

Better an end to suffering than suffering without end

If something is troubling you or your organization, often the greater pain is doing nothing and suffering inactively for a long time, rather than going through a painful change.

Good things don’t happen to those who wait

How often have you heard some amusing story start with “When I was just standing in line…"? Usually nothing interesting happens in line, so try to avoid them. If you already have a queue, make it transparent, and if it grows infinitely (like bugs to fix), you probably have a problem.