SAIP: Software Architecture in the Future

This is the last chapter of the book. Somehow, I feel that most of the contents here should have been placed either in the prologue or in the preceding chapters. For example, the evolution of software from subroutines, modules, objects and frameworks should have been mentioned earlier to give the reader an idea of how software has evolved.

This chapter mentions the shortcomings of the some of the techniques introduced in the previous chapters and I am glad that the authors acknowledge those shortcomings. For instance, in Chapter 5: Achieving qualities, readers were presented with a very unclear description on how to proceed once the development team has a plethora of tactics that they want to employ. Chapter 5 suggested that from those tactics, one could easily pick a right type of architectural style to apply. I am doubtful that it is that simple. If it were that simple, then there would not be a need for all this discussion in the first place.

The authors also discuss the existence of documentation within a tool environment. Again, I feel that this really should have been mentioned in the chapter about documenting the architecture. I agree that the authors might be wary about mentioning tools that they have neither used nor analyzed closely. But a brief mention of those tools might actually be helpful. After all, those tools are used in practice so they must be beneficial in some way. And more readers will be familiar with it compared to the Dali tool that was discussed extensively.

I appreciate the book devoting a sidebar to software architecture in education. However, regardless of how many course you take in the university, software architecture cannot really be taught. You can be exposed to a series of techniques like what was done in the book but then again, you only really learn those techniques if you apply them in real life scenarios. And that's why I am a fan of classes that have lots of projects. There are many things that have been left out from this book (and judiciously so) for the sake of keeping it simple. As the title of the book hints, software architecture is something that exists right now as a form of practice, and there has not been any significant advances in trying to codify the theory of it.

This book is an attempt to describe software architecture. It's not easy task, and while the book could be improved, it does a pretty good job at it.