When you start to ask around to architects in IT be it purely IT or software, system, solutions, cloud, enterprise… there is this one book that is always coming back in the discussions. The Software Architect Elevator by Gregor Hohpe.
Gregor and I have never met but I can relate to his path: we have both worked from traditional enterprises and digital companies, some of them in the middle, working all kind of roles in the IT structure, we both spent some time working in Japan (we were there even at the same time in 2012), and one of our main focus is helping with technology transition or transformation. I hope one day I will be as wise and knowledgeable as he is.
This book is about what it took and what it still takes to produce great architecture, architecture practices and great architects. The author brings his technical writing skills to elaborate on topics around digital transformation but also on topics rarely described in diagrams with boxes and arrows: the mighty soft skills. By far, the chapter on Communication has been the most interesting to me. I have met great architects during my career, communication were rarely included in the lessons.
This book can be read by anybody interested in helping a traditional company to transition to digital. It is structured in easily digestible chapters and parts, sufficiently independent that the book can be read at random, almost. So I have cherry picked some sections, recombined them, and related to my own experience, also at random, almost, too.
Fear
The fear of code. At the moment I stepped out of software engineering for architecture, I could not help but be amazed by the length that management goes to drive people away from code. It’s the vendors’ delight: vendors can charge more for abstracting code for customers.
In the past few years, there was a proliferation of no-code tools, and I don’t deny that they are convenient and fast for the easy stuff or prototyping. But “drawing boxes and arrows and hoping the machine behaves properly” has its limits and any serious integration needs code. Edge cases, performance, ownership, versioning, there are so many reason to develop your own tools. So why the legos and colourful bricks? They do like nice and it gives management a feeling of control. That’s important too. Configuration over code.
The fear of change. Again, another tale I could relate to Gregor’s experience is that when I went from engineering to architecture, I noticed the teams were seeing their work differently depending if there were from traditional or digital companies.
In traditional companies, the teams were looking for making things work, no matter how (sometimes with dirty hacks), then hope for the best. Which is always nice (when it works) but never enough. Because problems and failure happen. Or even worth, the system needs to be upgraded and the dirty hacks and fixes don’t work anymore.
Back in digital companies, failure is seen as unavoidable and part of the daily routine. We made sure to be able to recover as fast as possible (monitoring, version control, automation).
That’s what Gregor explains with MTBF: mean time between failure and MTTR: mean time to recovery, because it almost doesn’t exist in traditional enterprise.
An explanation for the missing MTTR in traditional companies is given a few paragraphs later by elaborating at the reversibility. From my experience, the undo mentality applied to configuration is a plague. It often happens working with vendors who don’t have configuration versioning. In digital companies, when things break, the idea is rollbacking fast to come back to stable state, automatically, without modifying any configuration.
References
This book, a reference in itself, is also a bible referencing lots of other references. There are two types of references.
The first type is all the pop-culture references such as The Matrix, Shrek or Lego Pirate ships. They are not always happy, even sometimes doubtful (I was expecting more from the Architect in Matrix).
The second type is other standard of the industry, among which:
– Books written by the same author like Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
– Martin Fowler’s books like Patterns of Enterprise Application Architecture
– Wardley mapping
That’s more books to read to for me, and they will probably contain more references. And these references will contain other references. It will never be over. But… Understood? References. Many of them. Chains of references.
I also discovered or put words on concepts I already knew. These words are more technical and fortunately readily accessible on wikipedia:
– Tuples space. A memory paradigm for distributed computing.
– Shift-left testing. Test early, test often. This is test early. I didn’t know it had a fancy name.
– Cargo Cult culture. Hoping stuff will fall from the sky, because you do certain things you have observed elsewhere, where it worked. This is a fascinating story. I hope it’s true.
Beliefs
A benefit from this book in my opinion was to shake beliefs and to articulate internal concepts. Like the Culture Map book before, I felt less alone with my experience and could relate with the author on specific events.
Let’s start with the obvious words on ideas I already had.
– In traditional companies, there is a motto which is “never touch a running system“. This is so wrong [1] well, don’t touch if you don’t know what you are doing, of course. But you should always be able to touch a running system otherwise, and I have been fighting a lot against this. Automated testing, continuous integration, low MTTR should allow touching any system any time. Preventing touching a running system is how you stale innovation.
– never send a human to do a machine’s job. Humans make mistake, machines don’t. Automate all the things. Don’t exhaust yourself on stupid repetitive stuff.
– Be careful while outsourcing. One of my favorite take out from this book is about outsourcing: outsourcing IT has severe drawbacks in the digital age, because it excludes the organization from the critical innovation cycle. But the idea of outsourcing everything is so omnipresent in every industry because “it’s so much cheaper”, and I felt so alone having a different opinion for so many years. There is a great cost to outsourcing IT, for it is the backbone of a company transformation.
– Digital transformation is about moving from efficiency based thinking to speed based thinking. Traditional companies optimize for efficiency, with reducing cost in mind. Digital companies think about speed first: time to market has to be the shortest possible. Sometimes in this case, it makes sense to use a rocket launcher to kill a fly.
And then, here are some concept I discovered, putting new words on new ideas.
– Throughput versus latency. When design system, look for optimizing organization and architecture to reduce latency and augment throughput while staying human. This is a delicate balance. Create self-service provisioning systems. Reduce meetings which require synchronization from many people. Publish any documentation or technical (non confidential) emails that you write within the org to be searchable later. And so on.
– Organization internal black market. I had already observed black markets within companies, but didn’t know they were a thing, and detrimental to the org on the long term. Black markets are hidden networks within organization where things get done faster, but out of the processes, documentation and democratic access. You know… You need to deliver X, and the team doing X is following a busy queue process, and it’s slow. Buuuut… You know a person in the team, and asking this person on WhatsApp gets X done in 30 sec. That’s a black market.
– Standards and governance. Enforce standards on the interface or the infrastructure, not the tools or products. One source control system and freedom to choose IDE. One HTTP protocol and freedom to use any web browser.
Governance can originate from:
- decree, when they make sense (cyber security),
- infrastructure, when you can optimize one way of doing things (Continuous Integration and Deployment)
- necessity, when choosing one solution over another one has a considerable advantage in economical constrained environment.
The idea of governance is focusing on resilience, avoiding vendor lock-in and environment fragmentation.
Humor
Beside the funky references and cliché analogies (I can’t ride an elevator without giggling these days), this book is a pleasure to read for its relaxed tone. There are also a few passive agressive jokes, one of my favorite was about the “learning” or “smart” devices taking into account a large amount of various feedbacks.
The author wishes we could apply this label to more project managers.
Read this book if you are even remotely connected to architecture in systems, the Communication chapter is gold. Then ride the elevator back and forth between the penthouse where decisions are made and the basement where things actually happen.
Then come back to this book, relate to new experiences. Damn, it works. Learn, remember, repeat.
- La Horde du Contrevent : review - 13 October 2024
- For Whom the Bells Tolls: review - 4 August 2024
- Self Aware On Air Neon Sign - 8 June 2024
References
| ↑1 | well, don’t touch if you don’t know what you are doing, of course. But you should always be able to touch a running system otherwise |
|---|