Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

I recently received my copy of the book, and the kids think it is utterly awesome to find my name on the copyright page as a Technical Reviewer. For what it is worth, I think it is pretty cool tool!

I spent a lot of my free time last summer reviewing the roughly 550 page draft on a chapter by chapter basis, and ultimately I feel like I helped Mr. Abbot and Fisher deliver a relatively solid treaty on the subject matter. I would suggest that the title is quite apropos  in that they focus the majority of their effort on the less technical side of Scalability, and if you are looking for a book that delves deep into the technical aspects of scaling, this likely isn’t what you are looking for. Where they do speak to the technical, it is primarily about scaling Web and takes a bit of translating to non-web based architecture.

Additionally, if you have ever worked at a large organization, measured in the realm of hundreds of thousands of employees, then you likely already have a firm grasp of many of the tenets  proposed herein; though you may find some new manner of thinking about them. As the subtitle clearly articulate, the book is about Organizations, Processes, and Architecture; thus two of the three main topics are specifically non-technical. Engineers and Architects should not be surprised when they pick up the book and discover this.

The book follows a logical pattern by first addressing scalable organizations, then addressing scalable processes, and finally discussing how one goes about scalable architecture. This seems very reasonable to me in that if you do not have the right people (organizations) focused on the right things (processes) then you will not be designing the correct architecture, rather you will be designing an architecture that address (perhaps) less scalable processes due to those processes being defined by an organization that doesn’t approach the defining scalable processes with intentionality. Which means that if they happen to get it right, then all is good; but they are more likely to get it wrong.

Many people use the terms Scale and Perform interchangeably, and these two fellows do a fantastic job of explaining why that is incorrect and precisely how so; many others believe that if their design has proven to scale from 1 to 10 to 100 to 1000 then it stands to reason that it would continue scaling, which is again a fallacy that too many startups fall into. If you have never designed, engineered, nor managed said activities for an extremely scalable system then this book is a great introduction to what that might successfully look like. If you have experience with building scalable solutions, it is still a good read and can help define and challenge some of your currently thought processes, I definitely suggest buying it and giving a copy to your project manager and leadership team!

To be clear, I don’t get any sort of royalty for you buying the book; and I reckon that the majority of my technical brethren can live without having read it. However, I’ve met a large number of people, typically small shop vendors attempting to sell a product to my large global organization, who could have really benefited from reading this prior to designing the product they were having. The number one reason large organizations do not invest in your company and product? You simply do not scale and you lack an understanding of what we are talking about when we necessarily broach the subject.