“The Art of Scalability”? At first, I thought that this was going to be one of those Technical Bible’s that compresses a lot of information into the story-so-far type of books, perhaps condensing a lot of know-how from the likes of HighScalability.com. How glad I was so wrong! Instead of being a collection of technical trivial implementations, the book sets its goal clear: how to engineer the perfect processes for those imperfect human team.
The book uses an effective background fictional story of the company AllScale with their flagship product being a Human Resource Management (HRM) system. As the book takes the journey over various facets of enabling a scalable organization, you may even be forgiven for imagining that you were the CTO for LinkedIn.
The introduction was pretty clear that the authors’ view of the most common (and easily fixable) scalability pitfalls is not the technology, nor the hardware, but the actual organization: the people and the organization’s processes. A remark was made that the issue of a scalable organization was a big problem way before the internet era. The book is very quick to tackle these issues in the first two parts of the book.
The third part of the book is titled, “Architecting Scalable Solutions.” By the time I got to this part of the book, I thought that the authors were done with processes and were about to move onto some technical jargon. My expectation was wrong, but it was a refreshing part!
The authors talked at length on how processes may be setup so that the organization can scale further. What do I mean? Usually, software organizations have the architect who is the one who says what goes without much justification. Even if the architect is a gifted and talented person who can make the technical bits scale, the organization cannot scale. He is the single point of failure: what happens if he leaves, or for an extended period of time he is unavailable? (Holidays, you know!) The orginization is held back!
Ergo, the book encourages that everyone within the organization works as indepedent teams and yet feel individually empowered. This is not to mean that each team has free reign where technical implementations does not align with the corporate strategy, or where the technical implementation risks the resiliency of the entire system! Instead, the teams report to an architecture forum board where they are able to hash out if their empowerment is in line with corporate strategy and policies. The architecture board members are encouraged to change often, so that the knowledge is distributed throughout the organization; even asking for the non technical folks to be part of the board.
The last part deals with “other” things related to architecture. One of those sections is how to encourage expontential capacity and growth with a cost line of the minimal gradient possible. Lots of interesting ideas!
In summary, I recommend this book to anyone who is involved in software development. I have been meaning to write this review for over seven months, but not a day goes by where an idea impressed by this book is recalled.
It’s a game changer; an organization changer!