The new world doesn’t reward architects who draw diagrams while sitting in the ivory tower. It has a lot in store, though, for hands-on innvovation drivers and change agentsGregor Hohpe
I completed Gregor Hohpe’s book The Software Architect Elevator: Redefining the Architect role.
I did enjoy the book. It’s a great read. I would strongly advise anyone interested in system architecture to pick up this book.
Here are eight lessons I learn from Gregor Hohpe’s book:
1- Is this Architecture?
Before I read this book, I thought it was only me who was confused about the definition of architecture, but it turned out it was not only me! We need a way to distinguish whether something is architecture in the first place, and this is where definition becomes handy. Here is a good explanation of the architecture
The set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity
2 – Articulating an architect’s value isn’t an easy task
Articulating an architect’s value isn’t an easy task. First, we need to understand that an architect isn’t
- Senior Developer
- Project Manager
Architects bring value in several dimensions – here are a few.
- Every system is made up of different components. Architects can look between elements to make sure interdependencies are well understood.
- Architects should always work toward reducing complexity.
- Architects articulate strategy
Architects see both sides of the coin and balance trade-offs in line with overarching goals and principles
3- The Architects elevator
Architects fill a vital role in organizations, they communicate closely with technical teams, but they can also communicate with upper management without losing the essence of the message. They can ride what Gregor calls the Architect elevator.
4- BAU is Business as Unusual
We hear every day the word BAU(Business as Usual). This is merely true in real life. Nobody wants a static system that never changes or gets upgraded. Constantly changing systems are always in need of supporting various business activities. The rate of change is the primary factor that influences architectural decisions, so changing a system is equal to business as unusual.
5-Questions and Decisions making
A good architect is a person who knows the right question and doesn’t necessarily have the answer.
Questions and decisions are at the core of being an architect. When you decide something, don’t think along the lines of bad or good but instead does it fits for purpose or not; even a perfect decision would have a downside – so always think about trade-offs
6- You can’t manage what you can’t understand
Architects must help close the gap between technical knowledge holders and high-level decision-makers by clearly communicating the ramifications of technical decisions on the business.
That led us to communication! Every single interaction with senior management is a teaching opportunity. Here are a few communication tools offered by Grig:
- Build a ramp, not a cliff: Consider your audience’s technical ability when you talk about a complex technical topic. Slowly building out a ramp using a few words, you can manage to involve someone who isn’t profoundly technical in the decision-making process.
- The whole is much more than the parts: When you look at a box of LEGO, you don’t see individual bricks. Instead, you see an exciting, fully assembled model such as a ship. This is how architecture should be presented.
- Learn to write for busy people: Organizations are full of boring documents that remain largely unread. Writing for busy people is an essential skill for an architect.
7- Control is an illusion
We would like to believe that top-down control is possible. However, every practice shows that top-down control is impossible to achieve.
3 gaps can make control an illusion: Knowledge gap, alignment gap, and effects gap.
The best way to control ironically is autonomy, as it accepts the gap and avoids operating in an illusion
Enablement, feedback, and a clear strategy are critical to successful autonomy
8 – The Black market is not efficient
Grig mentioned that he was allowed to make ten million tech decisions, but he had to obtain management approval to purchase a 200$ ticket. By the time he got permission, often the fare had increased. These types of organizations are intrinsically aware that their processes hinder progress. That’s why such organizations tolerate the black market.
How to know that your org has got black market?
If the answer to ‘how long does it take to get a server?‘ depends on who’s asking ‘ then you have a black market.
Why the black market is wrong?
The black market stifles innovation because they don’t provide equal access to resources and makes it difficult for a new member of the org to gain traction because they lack connection to the black market. Obviously, the work in the black market is undocumented.
How to beat the black market?
The only way to avoid the black market is to build an efficient white market that doesn’t hinder progress but enables it .self-service is a great tool to starve the black market.