"The Process of Software Architecting" looks like it could be read in one sitting. Don't be fooled. It is one of the most informative and thought provoking "job discussion" type books I have read in a long time. I made notes in the margins on page 1 and continued to the end.
Another surprise was the preface saying both architects and students are the target audience. True. Students won't get the deepness of it, but they will still learn a lot. Finally, the authors are both IBM'ers but it doesn't read like an IBM book or have an IBM slant. While the case study uses JEE, the authors summarize relevant knowledge beforehand.
Ok. Enough with the surprises. This approachable book is visual and list heavy which makes for easy understanding. Consistent bold keywords help readability. I found myself skimming some parts where the visual said it all. The appendices provide a tabular summary of much content.
For the 200 page case study, they have tasks defined in a summary box. Each task has steps along with checklists/pitfalls/best practices where applicable. I REALLY like this format. I particularly liked the emphasis on providing a mental map/thinking as an architect.
While the case study is simpler than real life, it is supplemented by examples later. My only complaint was the term "right-sizing" to mean scaling small vs large teams. Since this word was hijacked to mean layoffs, it is emotionally charged. But that being my only issue with the book is still pretty good.
I strongly recommend this book for anyone who is an architect or wants to be one day.
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
I don't think it's that good. I bought this book following the 10/10 score here, but I read the first 60 pages (of 300) and did not like what I read so far. May-be the good part is still to come, but the first 4 chapters are disappointing at least when you see that score given here. It is full of vague definitions, which then are commented by the fact that the use of this terms probably does not apply to your situation, since there is no consistency in them. The definitions are mostly what the Dutch call 'kicking in open doors', meaning something like saying what is already said lots of times before and what we all know. Summit of this is for example figure 2.1 on page 10, chapter 2. Three boxes, three arrows. Boxes containing Architect, Architecting and Architecture. Arrows containing performs, creates and results in. And then a page explaining that the Architect performs Architecting and that that results in an Architecture. Now really?? Ok, it is not that bad always, but if you give it 10 out of 10, I give you my view on it.
I agree that particular diagram is less than insightful. Have you gotten to the case studies yet? I f not, I recommend skipping to that section. The book changes at that point. (My copy of the book is in the office so I don't have the page # on which the case studies start.)
Once you've read a case studies, I recommend posting a review on Amazon if you still the book is bad. As of right now there are four 5-star reviews and no others. A different perspective will help people who feel the way you do see whether the book is for them.
No I haven't reached that part yet, but I am almost there. I was already hoping that after the 'definition part', the books exposes the brilliance for which you gave it that ten horseshoes. Thanks also for saying this to me, because I was kinda giving up on this book to get interesting, and was reading it less frequently. I will post a review when I finish it.
Jan de Boer
Joined: Dec 10, 2010
Author/s : Peter Eeles, Peter Cripps
Publisher : Addison-Wesley Professional
Category : Project Management, Process and Best Practices
Review by : Jan de Boer
Rating : 6 horseshoes
Ah sorry but I really do not like this book. Now first I must say, I can have very different opinions then the crowd. Sometimes I dislike movies for example that other love. I can remember a movie called oceans' number 12, I think. Lots of famous stars in it, but I just hated it. I can remember certain music records as a teenagers my friends loved, I hated them. I am kinda strange and independent.
But what I don't like about the book is, what I already stated in the previous post, it tries to over define all kinds of things. I don't like that because the process of architecture, software development, uses very inconsistent vocabulary. But if this is the case, why not just agree on the fact that these words are used in a different way in different environments? Why on every term quote all kinds of books? Just agree to disagree, and try to explain certain pitfalls and good practises by some examples instead? Also the definitions are useless I think when in all software developing environments they are used differently. You should know what it means in your environment, and this is not the same as tried in any book anyway.
Then it gives a certain empty cabinet, procedures you could follow. But if I work in a company, this is mostly already decided for me, in a method the company has chosen. And the exact organization of the shells is not that important. It is important you put something logical inside it. And then it kicks in some open doors like: this procedure could be simpler if your project is small, and more thorough if the project is complicated. Now really? And also it comes with remarks like: the order of the process in not exactly defined. Yes I know that too. It never is.
So it really did not tell me much new stuff. And what it did told me, was packed in what I think a over academic style that in the end really irritated me. In fact, I stopped reading the book at page 260 of about 300. I learned a few new terms from it. There is a check list as appendix I think is useful to check if you have thought of everything. But I would rather read a book that tells me what I can put 'on the shells of the cabinet'. The books states that this is not such a book and that there are other books who explain design and architecture paradigms. I think I will read those books then.
I will still give it a six, since it's not badly written or something. In the fact that there are a lot of errors in it. But I find the aim of the book useless, and the style over academic. Again and again some quote from some study like the writers want to prove they read all those....
"Architect" is a noun, it is not a verb. "Architecting" is not an English word and is typically used by those that don't really understand the process of designing software architectures. It is a poor title.
Jan de Boer
Joined: Dec 10, 2010
By the way, I cannot post a review on Amazon, Jeanne, since I never bought something there. This frustrates me, because I REALLY dislike the book!
No need to apologize. Different people have different opinions. That's why the content of a review is better than the number. I tried copy/pasting your review into the end of mine at Amazon. (with your name and a link to here) Not sure if they will let that in, but we will find out in a day or two.