Customer Reviews

The Art of Systems Architecting (Systems Engineering)

5 star:		(4)
4 star:		(4)
3 star:		(2)
2 star:		(0)
1 star:		(0)

 

 

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.

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?
Tom@Gilb.com, August 24 2002.

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.

I waited for a chance to use this book before writing a review. For the past two years, I use it only when I need words to describe to the lay person "What" System Architecting is. But for practical system architecting technique, this book won't get it for you.

This is a good book. It has some brilliant insights. It also has some mundane material. It's the only book on SYSTEMS architecture and should be read by all architects as well as systems engineers. Software engineers could learn from it too.

As a start on describing systems architecture (as opposed to technical or business architectures such as software, hardware, security, information, network, etc.) it does a superb job. What I would like to see is more. I sense from the books footnotes that some material from the first edition has been elided. A third edition should include recent journal articles viewpoints and any material the editor cut from the first edition.

There are many useful insights and a good overview of systems architecture. The definition of systems architecture was good.

I found no significant errors although some of the material included was not as relevant as some that was omitted. Newer material that has been published in journals needs to be included.

I would like to see a better relationship drawn with systems engineering, business strategy, six sigma techniques, etc. Some of the material included may have some architectural significance but that was lost in describing systems engineering and quality approaches rather than contrasting and comparing them with SA. Perhaps a systems engineering companion book to be read first could handle this sort of material.

The heuristics were excellent but incomplete. This is not a fault of the author but the fact that the field is new and just being documented.

The examples used were those available. I would like to see others but many people will not let that information out for use. Certainly an example of business as a system and noting how systems architecture relates to business strategy would be a useful addition.

Some minor glitches such as not defining acronyms before use were annoying but did not impede learning.

I would like to see appendices with summaries of the standards referenced. I would like to know a lot more about the schools, curricula, and courses relating to SA that were mentioned.

The research seems incomplete. The sources used were used well but there are others that did not get used. Some used did not seem to be as pertinent. I wonder if the editor gave the authors a deadline so they could publish the second edition.

This is a good book. It can be better. Hopefully a third edition will fill in and extend the coverage, provide additional examples and more subject matter for reference in the appendices.

If you have any interest in systems you should read this book. It would be 5 stars except that it could be improved. Since there is no other competing book it is infinitely better than the alternatives. Other books drop down an implementation level and do technical or business architectures even though they label the book as systems architecture. Those would make good follow on reading for domain and discipline engineers but all engineers should read this book.

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.

A much better alternative: "Process for system architecture and requirements engineering."

Buy this book only if you have some money left.

If you have questions as a practitioner of systems architecting about your overall architecting approach then I would highly recommend this text. I would also recommend this as a reference book for a systems architecting class at the advanced graduate level. It does provide a balanced view of the discipline for journeymen. The view is presented in multiple dimensions such as builder-architected, manufacturing systems, systems science, and social systems domains. The chapter on models and modeling is very useful to the beginning architect but is somewhat high level. The architecture frameworks chapter is outdated and is shallow. The integrated modeling methodologies (Hatley-Pirbhai, Q2FD) discussion is very brief, but has references for further reading. The section on the systems architecting profession causes the reader to think deeply about the profession.

If you are looking for a system architecting self-help cookbook, this isn't it. Although the appendix lists architecting heuristics, I doubt that those 12 pages alone would be worth the cost. The book will disappoint software-only system architects since much of it is clearly focused on software/hardware co-development and manufacturing systems development.

System architecting is still in its infancy, and this book provides a critical element to that profession's maturation. It identifies some of the domain's critical attributes, but fully understanding this text requires some system architecting background to apply what is being presented.

This book provides multiple perspectives to better understand how to take an 'out of the box' perspective when approaching systems architecting. You'll get out of it what you put into it. Enjoy.

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.