The Software Architect Elevator

Not long ago I read Clean Architecture, an incredible book about software architecture that left me really wanting to dive into something more modern... Clean Architecture uses Java heavily to present its ideas and concepts, and although the concepts are universal, there is nothing about developing software for the Cloud and the such. Then someone recommended the Software Architect Elevator to me and this is what I was actually looking for.

This is the first book "review" for this website! Is not really a review though! (Of course it isn't! Who am I to judge the work of this great authors?!!). So instead of a Review I'll just focus on two things: What I've learned, and what really stood out to me from the book!

What did I learn?

In terms of learnings, if this would have been my first book on Software Architecture, I would have said lots. But I don't think anything presented here is unique and it just really compliments what people already know! Differ making decisions around your architecture until you really have to commit to something, the importance of automation, don't send a human to do a machine's work! And all this good stuff, but what was new for me?

Well the whole concept of the elevator was really a great metaphor, I think roles in Software Engineering can be poorly defined, and they change so much from company to company. I've got the opportunity to work with different kinds of Architects and I've seen two examples that are presented in the book:

I've had the opportunity to work with Architects who are so far removed from the Engine Room (As the book calls it) that, as a Software Engineer, you can only question what's the value of having this people around? I am sure they are great and all but when they get so detached from the work that's going on in the Software Engineering teams, is really hard to understand why such role exists.

On the other hand I've got the opportunity to work with a great Architect who was not only incredibly talented on the Technical aspects of Software Architecture but also a great leader who step up when we lost our Head of Engineering and kept everything running smoothly during uncertain times. Ironically I was really unsure we needed Architects at this place when they decided to hire them because of my previous experience with them, but how wrong I was.

I would say I learned how important it is to have Architects that are able to ride the elevator up and down, and are a true force for change within the organisations, I hope to see a future where there are more Software Architects like that around.

What stood out to me?

Well what really got stuck to my brain had nothing to do with architecture itself but it was two quotes from the book:

• APIs have two versions: the one that's deprecated, and the one that's almost ready but not there yet... This just made me laugh because is true, and its self explanatory, I'll be surprised if this isn't the case for everybody!
• Software is eating the world, and if that's the case there is two types of people: The ones who can tell the computer what to do, and the ones that will be told what to do by the computers. This is something I've believed since I decided to study Software Engineering back in my country... Going back to what the book says: Don't send a human to do a machine's job, with AI growing and learning more each day I can only wonder what the future would look like when my son is older and what sort of careers are going to be out there!

Conclusion

If you are at any level of the Software Engineering career path, please read this book, its an easy read, very well structured and full of great insights! Gregor Hohpe did a really good job with this book and there is far more to it than the little bits you could read here!