As the digital economy changes the rules of the game for enterprises, the role of software and IT architects is also transforming. Rather than focus on technical decisions alone, architects and senior technologists need to combine organizational and technical knowledge to effect change in their company’s structure and processes. To accomplish that, they need to connect the IT engine room to the penthouse, where the business strategy is defined.
In this guide, author Gregor Hohpe shares real-world advice and hard-learned lessons from actual IT transformations. His anecdotes help architects, senior developers, and other IT professionals prepare for a more complex but rewarding role in the enterprise.
This book is ideal for:
� Software architects and senior developers looking to shape the company’s technology direction or assist in an organizational transformation � Enterprise architects and senior technologists searching for practical advice on how to navigate technical and organizational topics � CTOs and senior technical architects who are devising an IT strategy that impacts the way the organization works � IT managers who want to learn what’s worked and what hasn’t in large-scale transformation
I don't know whether this book resonates so well with me because of the time when I read it, but I gosh, this book is a great one for aspiring and also practicing architects. I can certainly say that I wished I had this book when I was first in the architect role, but also at later stages it would have provided me with an extra boost of confidence for the way I do things.
Because Gregor argues for a different spin on the Architect role: The enabler of digital transformation that connects the various levels of engineers, product, management, etc. In German we would say "Hans Dampf in allen Gassen". More broad-generalist than specialist. Change agent at heart. Understands much more than just the technical aspects and is able to bridge between the different parties.
In short: From his perspective the Architect has a meaningful role to play as connective tissue in an organisation to operationalise the strategy of a company.
A lot of the topics that Gregor references, are usually not on the top spot for want-to-be-architects to read. And from own experience I can tell that often peers were baffled when I, an architect, was curious about product management, organisational theory, strategy frameworks etc. But for me it makes so much sense to be aware of these and put them into consideration when devising the way forward. Contrast this with the Architects I've encountered in my career who were often very good engineers with a lot of deep technical expertise. But most of them didn't want to get involved in these peripheral topics. I think that's a pity, since the solution space becomes so much more interesting if you interconnect and integrate the various aspects of digital product development. The best solutions are the ones that require only very little code to be written (by rearranging how we actually do things).
Coming from that angle this book contains a lot of peripheral pointers to various topics that Gregor considers important for his vision of the Architect role in an easy to read fashion. If you're searching for a technical book on how to do architecture for a certain problem, this isn't the book you should look into.
I will read this one again and can only recommend it to everyone in an Architect or related role.
A practical and useful guide for anyone who bridges technology and the rest of a business. Gregor has a wealth of experience as a Chief Architect, CTO, and consultant at global financial institutions, digital startups, and global cloud providers. He gets what is important about technology for a business, and how to communicate that.
The section on how to communicate is outstanding, concrete advice on how to write memos, presentations, and create diagrams from someone who has both on both sides of the executive / techie divide. Gregor has seen it all, and knows that one size doesn't fit all.
I strongly recommend this book for anyone in a technical leadership role who needs to communicate with other parts of their organization. People on the less technical side who work closely with technical folks would probably also get a lot out of this book.
A new perspective to architect's role in IT companies. There are a lot of definitions for architect’s role and it is hard to explain the tasks and responsibilities of architect. Author provides a new perspective for this role. He explains different aspects of architect’s role in IT companies and examines them based on this new point of view. Author also provides excellent recommendations for architects that can help them do their tasks better and lead their companies toward new goals. Some sentences from the book: “Rarely is an architecture simply “good� or “bad.� Rather, architecture is fit or unfit for purpose.� “Understanding complex interrelationships between system components and influencing them to achieve a desired behavior is what architects do.� “IT architecture is a profession of trade-offs: flexibility brings complexity; decoupling increases latency; distributing components introduces communication overhead. The architect’s role is often to determine the “best� spot on such a continuum, based on experience and an understanding of the system context and requirements. A system’s architecture is essentially defined by the combination of trade-offs made across multiple continua.�
Mr. Hohpe has done a wonderful job tying together a broad range of information critical to success in software architecture. As a software architect myself, I found The Software Architect Elevator a refreshing and clear-eyed take on a profession that's going through a major transition. I'm grateful for a voice that both supports some of the conclusions I had already drawn, and also provides a helpful guide to help me better understand where I should be going next.
His viewpoints on organization are part of a growing movement calling for specific organizational transformations necessary for companies to survive in a digital economy. I highly recommend this book for any software architect that wants a modern, insightful perspective of our profession. If you are not an architect, don't let the technical references fool you - there is a keen understanding of the strategic, human, and business impacts of his suggestions. Given the growing realization that technology has become the driver behind business as well, it would be advantageous for anyone to read, regardless of which floor you sit on in Mr. Hohpe's architect elevator.
This entire review has been hidden because of spoilers.
The best book I've read about the role of an architect.
Leading tech companies such as Google are built on great software architecture without any designated architects in their ranks. But for most companies, IT is not seen as the principal innovation driver, and having an architect spending its days in the elevator trying to communicate ideas to make code fills their business job is more than welcome. But we need to clarify the architect role. This is the subject of this book.
It's not a technical book. There are no diagrams or snippets of code. There exists many good books about architecture, but before this one, I’ve never read a single good-enough book about the role of a software architect. To be honest, I also thought most companies would be in better shape without architects at all. This book changed my opinion on some points.
Software Architect Elevator is among my favorite readings. Really. I love every page of this book. It is filled with interesting stories, inspiring quotes, powerful analogies, interesting links to blog posts, and varied book references. This book is very different from the author's previous book on patterns. Both are great, but for different reasons.
The book is remarkably written. Each chapter is short, beautifully illustrated, and so much fun to read. The content is opinionated but thoroughly researched. It’s the kind of books few persons could have written. You will discover a new face of a well-known role. You will learn about so many topics--how to make decisions, how to manage organizational systems, how to draw effective diagrams, how to communicate ideas, how to lead change, and so much more.
The book will benefit the most to the software architect working in a large organization. But I think developers, managers, and executives will learn a lot from this book. Yes, that would make a lot of people in the elevator. But the book contains many words of wisdom that are widely applicable, not just concerning architecture. It's a unique book.
This is a mandatory reading for any serious architect. Gregor Hohpe sheds lights on a plethora of daily problems, mostly cultural ones, that an architect can help to solve, therefore, expediting Digital Transformation
I just did not get it. In the beginning, it was fun, it was OK in the middle, and it was absolutely tedious and boring in the end. I mean, everything that was put into this book is valuable. Just several things stand out:
a) it's absolutely common sense stuff b) there are 41 articles barely related to each other. Feels like someone was just putting their thoughts in writing, changing the subject every few pages.
As with many books, it's fun but should have been a series of blog posts or a paid newsletter.
Great book! It emphasises how in today's world it's vital to bridge the gap between business and technology and how important the proper leadership is to achieve this. I really how the author sees the role of a software architect and responsibilities that come with it. He clearly states that to be successful as software architect, one must be able to communicate and convey his/hers ideas to people of different backgrounds (business and IT alike) and inspire them. I think this part of a job is often overlooked and people tend to focus on hard skills and knowledge of technology (which are obviously equally as important). I also appreciate the straightforward message that there are no silver bullets and every transformation requires both time and effort.
I enjoyed the book a lot while reading it. It is clear that the author has a lot of knowledge about the subject and he describes the life of a software architect from a new and fresh perspective.
Some of the chapters contain real gems of knowledge about the life of software architects.
The book covers a wide range of topics. They all revolve around architecture, the role of an architect, and the structure of an organization. You won't find any practical solutions here, but still a very enjoyable read.
Great first chapters and some good ideas throughout the book, but some chapters feel like fillers without much to add or too vague to extract information. I'd personally ditch the part on presentations.
Great summary of stories and experiences. It puts a lot of well known situations into extremely handy metaphors that make them easy to convey. Highly recommend.
It’s a must for those who are starting being an IT architect and for who already are, it’s a reminder of what’s the real purpose and the importance of the role in any company that is in a digital transformation
In a digital transformation time, the Software Architect Elevator is a must!
I loved every single part of this book, not only Gregor has so many insights and guidance for us architects that are part of big enterprises making the change to Digital Companies, but he is able to make it entertaining! Strongly recommended, a book that will be key in this turning point in the world of big companies.
If you were expecting a book on technical details, probably you would be disappointed. Fortunately, I was looking for a book to get an insight into being a Software Architect in a larger organization. And I got a lot of food for thought: organizational management, cognitive biases, queue theory, Wardley Maps, system thinking, and a lot more combine in a very cohesive way. Especially last by one chapter is very interesting, about additional dimension to perceive our work.
The disadvantage is that some chapters feel out of the context to me (e.g. diagrams) but they are not so numerous, after all.
The style of writing can be off-putting at the beginning (a lot of short chapters) but then you get the whole idea and it just 'clicks'.
This is a great read and source of pithy quotes. So my review is just going to be a list of my personal faves. These are all really nice ones to drop into a team meeting.
1) "If You Never Kill Anything, You Will Live Among Zombies, And They Will Eat Your Brain"
2) "Never Send a Human to Do a Machine’s Job"
3) "Control Is an Illusion"
4) "If the answer to “how long does it take to get a server?� is “it depends on who’s asking,� then you have a black market."
Not as useful if you're not at an enterprise - as the subtitle says, it's mostly about "redefining the architect's role in the digital ENTERPRISE" - if at your company you don't need to wait 8 weeks to provision a server, lots of the advice doesn't apply IMO. And you can safely skip the second half of the book (parts IV-VI). Nevertheless, it's quite a good read and you can learn some stuff from it anyway. :)
Author's "Enterprise Integration Patterns" books is timeless classics.
This book was a good read, however it could be squeezed to 50% of its current volume... I missed brevity. I was able to find needed brevity in the records of author's conference talks on topics touched by this book.
Book contains good references to other books/resources.
A stew of many suggestions and observations that were collected over time by the author. Reads like a browser bookmarks manager. Absence of cohesive narrative.
Traditionally, companies live and die by a fixed hierarchical approach where power and influence are garnered by climbing to the top of the ladder. However, recent decades have witnessed the rise of digital companies promising an economic disruption. Stereotypically, a smart young kid writes some code to change the way business is done and become rich in the process. We, in the public, then use their software for decades to come. Many companies still have not adapted to the new dynamic, so in this book, Gregor Hohpe tries to shine a path for software architects in these companies to take responsibility for adapting their businesses to digital realities.
This book’s central thesis tries to redefine the software architect’s role. Traditionally, their prestigious position was to define how software is designed for the entire company or division. Instead, Hohpe proposes that they need to be more agile and focus on integrating new digital products into a company’s culture. With prior work experience at Google, his vision corresponds to that of so-called Big Tech.
Personally, I work in software efforts at a major academic medical center that has sought to be at the forefront of the digital transformation. Seeking to be the disrupters, we are well-acquainted with the newer digital culture. Further, our non-profit organization is not driven solely by the bottom line and shareholders. Since my organizational culture has already progressed significantly towards an agile digital approach, I don’t reside in this book’s target audience. Hohpe’s work after Google seems to have focused on transforming organizations to be more like Google. My organization already looks a lot like Google in its approach to research.
Reading this book certainly conveyed peaks of deep insight to me. For instance, the section on organizations helped me think through ways to implement my software’s disruptive change. The rest of its contents are solid and reliable. Most of this book, however, contains insights already shared in existing literature with little new content to provoke pondering thoughts. That shortcoming prevents it from going from good to great. Its title addresses ambitious developers looking to advance their career, but is a lot more about the digital enterprise as a whole. Perhaps taking responsibility for that organization is the step more developers need to take.
In the modern digital world, the software architect must do more than just design systems. It is his or her job to combine the business and technology sections of the business to accelerate the rate of change. Only by rapid (and controlled) change can a company deliver value to both its customers and its shareholders. This is the thesis Gregor Hohpe's The Software Architect Elevator is built on.
You won't find descriptions of architecture styles or methods to analyze them in this book. The Software Architect Elevator focuses on the soft skills an architect needs to be effective. Hohpe starts by defining his concept of the elevator. In his or her position, the architect has the unique opportunity to communicate with both the top-level executives (CEO, COO, etc) and the technical workers who actually get stuff done. They can convey technical topics to upper management without losing the essence of the message and can translate the business strategy into technical decisions that support it.
The book is divided into several sections. The first describes the various ways an architect can act and the ways Hohpe thinks they should act. The second is how the enterprise should act in terms of systems thinking, automation, and change control. The third is in communicating architectures. The last few sections deal with analyzing the organization the architect works in and how to promote change. Each section has some great takeaways.
The book is conversationally written and is chock full of helpful tips and stories. It's a good read for anyone who is (or wants to be) a leader of change in their company. I'm a firm believer that architects need to be in the codebase to be effective, but this book doesn't require any technical skills to read and get something out of.
This book took a long time for me to read, and I had purchased this book after getting promoted to the role of an architect itself. The book has lots of wisdom for someone like myself who has just began his architect journey but I think even for experienced architects it has a lot to offer.
Some my key takeaways from this book were
It’s important that an architect who has now got access to the penthouse to not forget the engine room because that is where it is determined where you actually go.
An architect should not be just involved in presentation and strategy but he has also has to have connect with developers in the team, and for that it’s important to have a hands on.
So an architect is basically a connection between penthouse and engine room, he should talk with people in penthouse in their language of diagrams and he should be able to talk to people in engine room in their language of code and architecture.
Being agile is not just being fast, but going in the right direction and wherein your code changes can be deployed confidently to production, not deploying and then making the code work on production.
Also agile teams require a degree of freedom to take decisions and not take months to wait on something. Also infrastructure is an important aspect of agile, the infrastructure has to be done as a code more and more.
Also it’s important to unlearn something because doing the same thing which made you successful last time doesn’t guarantee that you will be successful using the same methods now.
These were some of things which were important to me, but the book really has lot of wisdom which helps architects migrate the treacherous waters of digital transformation with some kind of compass in this book.
This book does a good work at re-defining the software architect role in a modern industry. However, same as the "software architect" title itself, the book is very broad (while still being a fairly short read). The book contains many great anecdotes and recommendations, however, it can also be too broad at times as it fails to focus on a specific "architect". Rather, it's a book that broadly touches on many architect hats- sometimes it discusses enterprise architects, a hands-on architect/developer, a technical lead or a person leading the digital transformation in an organisation. As the result, its lack of narrowness on a specific role is as much as the book's strength as it is its weakness. It also fails to provide clarity on this specific topic. Therefore, I wouldn't recommend this to book to a person looking for a resource covering a specific software architecture-related role. The reader will often find themselves focusing on a "hands-on" architect, just to read about an enterprise-level leader few paragraphs later. With these caveats in mind, it is still a great read, though.
This is an informative, but not very coherent, book about the author's views on the Software Architect role.
It's an enjoyable read as the writing is quite lighthearted, and there are many interesting examples drawn from the author's rich experience. It's like having a chat with your grandpa where he tells you about his war stories and the life lessons he has learned over the years.
However, the book lacks a defined structured. My guess is that the author built this book from the ground up by finding interesting intersections between technology and management (e.g. Starbucks use queues, vertical vs. horizontal scaling organization), then group them together to form the chapters, and then group the chapters to form sections. While this bottom-up approach grounded in real-world cases gives the content authenticity, it also causes the ideas to feel scattered at times. If the author had spent more time editing the text and cutting down less important details, the book would be more cohesive and focused.
That being said, I'd still recommend this book for other senior software engineers and architects.
Je connais le travail de Gregor Hohpe depuis quelques temps, déja. Et je voulais voir comment il allait développer ses idées. Vous trouverez une table des matières très détaillée sur le site d'. Et si vous prenez le temps d'y jeter un oeil, vous comprendrez qu'il a du métier d'architecte une vision très complète. On parle donc dans ce livre de réflexions autour des systèmes logiciels et de leur définition, de communication avec les multiples parties prenantes d'un projet informatique, de politique (parce que dès qu'il faut faire bouger des lignes qui ne veulent pas bouger, on fait de la politique, qu'on le veuille ou pas). Je l'ai évidement dévoré par tradition, mais je crois que ce livre, qui réfléchit aux concepts à la base des projets informatiques, mérite d'être le livre de chevet de bien des architectes, qu'ils soient en devenir ou déja confirmés. Je me dis d'ailleurs qu'il serait bien que je le relise dans quelques temps.
The premise of this book is that architects should be covering as many "floors" in a company and be able to ride from penthouse (C-level) to engine room (engineers). This is a prerequisite to start digital transformation for example in big enterprise companies.
The book is a set of articles that are linked back and forth between them. All of them focus on a bit of a different angle of being an architect - from communication patterns to black markets in a company and starting the transformation.
So what do I think about the book? It's a good book. If you work as an architect this is the one you should probably read as it helps highlight some of the areas we do not alway pay attention to. I must point one thing though: as much as I appreciate the concise writing style it has put me to sleep a few times.
There is various feedback in some of the notes that may add one or two points of value. Overall this book is outstanding. I felt a kinship with much of the content and the rest is inspiring. This read has already contributed to my growth as an architect which I consider an endless journey. I wouldn't have it any other way. I will consider this one of my favorites that I will refer back to often for guidance. Particularly since I had to shelve it for some time to focus on another mandatory read due to a work assignment. If I had the authority I would make this a mandatory read for all architects in my organization. Well, at least incentivize it. I can appreciate the time and effort that went into this. My deepest gratitude to the author for writing THE IT Architect compendium.