The Art of Systems Architecting

This book is probably the most abstract one on my Software Architecture bookshelf right now. Each page in this book takes twice as long to read as a page from any of my other, more technical architecture books. Another book might say "Use UML, everyone else does"; while this book says "Given a particular model set and language, it will be easy to describe some types of systems and awkward to describe others [...]".Time spent reading this book is a good investment in my opinion, but only if you read it at a moderate pace and reflect. The listing and discussion of heuristics is especially valuable. For example, "The greatest leverage in architecting is at the interfaces" is a good heuristic and the book has an appendix full of them. Not only that, this book offers good discussions of what each heuristic means and why it applies.

Review: This is a great overview of the subject of systems architecture. It is already highly regarded in the systems engineering community. It is rich in useful detail. It gives a comprehensive historical view of the discipline. I found a large number of specific insights about the nature of architecture as opposed to engineering. The collection of over 180 heuristics is an interesting framework for the text. I can highly recommend it as a study to both novices and seasoned professionals. The guest chapters on political process and systems architecting (Brenda Forman), and The Professionalization of Systems Architecting (Elliot Axelbrand) are both valuable additions to the immense vocabulary of the authors. If I have one quibble it is that the book correctly insists on quantification of performance attributes as the only proper basis for architecture, certification, and engineering. But it so often denies the measurability of so called `soft' values - and remarkably includes things like `safety', and `environmental impact' in that category. I fear that setting too high a standard for quantification leaves us with mere ambiguous words. This of course is a widespread problem. I disagree, and will take up the discussion with the authors and the community - as I already have done. In addition I find a complete lack of examples, or discussion, about how `multiple performance and cost attributes' can be used by the architectural level to understand the architectural problem. There are far too many non-quantified models, and far too little insight as to how a systems architect would deal with the quantified attribute requirements of a system. Maybe in the 3rd Edition? [email protected], August 24 2002.

I am a professional software and systems architect. Also, I have designed, built, and teach an industrial course on architecting distributed object systems. Being a very active reader of the literature on software architecture, design patterns, and software development process, I can say: there is, in my opinion, no better book on the subject of the process of architecting and the realities of life as an architect. Herein lies wisdom. Grasp it.

The authors Rechtin and Maier first address the discussion of Architecting vs Engineering. Interesting. In Part 1 they focus on 4 architecting methodologies: Normative (solution based), Rational (method based), Participative (stakeholder based) and Heuristic (lessons learned). It's good to stress the importance of lessons learned and best practices, although worst practices are very important too. But is a methodology based on Heuristics a methodology? Chapter 2 describes heuristics as tools and this chapter is good to read. Part two of the book, four domains to use Systems Architecting, offers new insights by showing how systems are architected in "builder architected systems" (making products), manufacturing systems, social systems and software systems. Especially the chapter on social systems is good. Remember to ask yourself the 4 who's (who benefits, who pays, who provides and who loses) because these parties influence the acceptance of your system. Part three of the book focusses on models, modelling methodologies and design progression. Chapter 10, written by Brenda Forman, describes the Political proces. In my opinion the best chapter of the book. Every architect, every consultant (whatever kind of consultant) should read this chapter. Terrific heuristics ("Proof is a matter of having the votes", "the best engineering solutions are not necessarily the best political solutions") and good examples on something that a lot of IT professionals don't like: politics. But, as the book suggests: "You may well find the craziness of the political process distasteful - but it will not go away!" You can use the lessons of this chapter every day. Finally, Appendix A lists a lot of heuristics you can use. Recommended reading.

This book addresses the rather neglected field of invention, specifically invention of systems. Whereas most books on systems address either formal analysis of an already invented system or the process for keeping track of system descriptive data (classical systems engineeringt), Maier and Rechtin address the really hard issues of how does one invent a system from scratch. This book contains a general discussion of the process of invention of systems. Most importantly, the authors then tie this process description to a set of system invention / design rules that they refer to as heuristics. The heuristics are then discussed in some detail so as to improve the reader's interpretation and judgement in the use of these system invention / design rules. Examples are very useful in any craft. The authors acknowledge this by providing some useful examples of the application of the system invention / design rules to a number of different system problems. This book is a must read for anyone interested in or affected by artificial systems, whether they are technical, enviornmental, social, or other types of systems. Their clear presentation of a set of useful system invention / design rules together with a clear explaination of how to make practical use of these rules can assist any system architect in improving the level of maturity of his/her practice.