<< 1 >>
Rating: 
Summary: Understandable
Review: A colleague gave this book and challenged me to understand it, and if I truly understood it he further challenged me to write a review. Since I'm posting a review I obviously understood it. My first pass through the book was frustrating. I could not get a sense of what the author was trying to say, even though it sounded important. Each time I was tempted to admit defeat and toss the book back in my colleague's face some unseen force make me keep reading. By the time I reached the end I knew less about business specifications than I knew when I first started reading. I'm not a quitter by nature, so I went back through the book looking for clues that would point me to the elusive methods of business specifications. About mid way through I had a Zen-like flash of understanding and enlightenment. I'd figured it out! The author has skillfully blended the timeless work of the Grimm Brothers, Hansel and Gretle, with the surrealistic writings of Lewis Caroll. Here are the clues: like the Grimm Brothers' masterpiece the author drops little facts and ideas like bread crumbs throughout the labyrinth writing to subtly lead you to that supreme moment of Epiphany - understanding how business specifications can be married to object-oriented techniques. In case the reader is too dense to get it, he also draws maps in the form of diagrams. He fails, however, to explain the symbology in clear terms, and is equally obtuse when it comes to explaining the rules of his notational masterpiece. This is where Lewis Caroll comes in, and how I discovered the key to understanding this book in the first place. He litters the book with passages from Lewis Caroll's books. Not a subtle message, but one that certainly tells you how to read the book. Think surreal and pretend you are chasing a white rabbit and the quest for gleaning useful information from this book will suddenly have a purpose. As I said, I had a brief moment when the entire book made perfect sense, then, poof, it evaporated and I returned to the real world where I was utterly confused by the author's writing style and intent. The way I see it you have some options. (1) Avoid the book. Frankly you will not miss anything. (2) Buy the book and when or if your moment of clarity comes and you achieve enlightenment write it down before you forget it - and please share it with the rest of us. (3) Buy the book, attempt to understand it and, failing that, go ask Alice.
Rating: 
Summary: Avoid! The worst book I have read in years.
Review: I do not normally bother reviewing (let alone finishing) books to which I award one star. This is an exception because the related theme of this book, business rules, is an important topic and this book actually detracts from the acceptance of business rules as a fundamental approach to requirements and specifications. A scan of the table of contents shows a logical structure that will entice anyone who is interested in business rules to rush out and buy this book. Unfortunately, the logic and structure ends with the table of contents. I read through the first three chapters wondering when a concept would emerge. I continued to plow [painfully] through this book trying to follow the author as he went off on tangents that occasionally (and accidently I suspect) brushed against the theme. Enduring the worst writing I have encountered in over 25 years in the IT industry I was able to figure out that the author advocated a notation for representing business rules (like we need another modeling language), that business rules should be succinctly expressed (although the book sure wasn't) and business rules could be captured as patterns. The latter was an original thought that had merit and was even [inadvertently] reinforced by a fact presented in chapter 3 that insurance specifications first published in 1835 still served as a valid model in 2001. The only thing worse than the author filling 305 pages of rambling and incoherent writing that could have been boiled down to perhaps 25 pages is the fact that he emphasizes the need for readability on 39 of those 305 pages. I do not fault the author as much as the publisher's obviously poor editorial process, which allowed this book to make it to publication. If you are interested in how to effectively develop business specifications and express them in a coherent manner this is not the book. I recommend instead any of the books on the topic by Ronald G. Ross, C. J. Date's "What Not How: Business Rules Approach to Application Development", or selected works by John Zachman.
Rating:
Summary: Excellent! No need to upgrade when a new tool appears.
Review: One of my esteemed reviewer colleagues said, "the book is conceptual, not actionable". Good concepts are actionable. But leaving this aside, being conceptual is great! There are many books that need an upgrade when a new version of some tool will become available. (For example, there are hundreds of UML-specific books.) This book is not tool-dependent, and it will remain valuable for a long time to come. It shows all of us where to start and how to proceed when we have to write business requirements. In particular, it shows what can be reused, so we do not have to start from a blank sheet of paper. And when we read the clear, precise and concise business specifications shown in the book, we can see the difference between these specifications and volumes of "too much stuff" presented as business requirements and not read by anyone. It is a pity that the author shows business patterns only from finance, more are needed from other business areas.
Rating:
Summary: 20/20 Hindsight
Review: One valuable lesson I learned is to read reviews before buying books. I recently discovered business rules as a methodology and have been buying every book on the subject that I can find. This book looked like it would give useful information, but didn't. There may be a few good ideas buried within, but they are hidden by academic prose and ideas that are just not implementable in the real world. Anyone who claims they have implemented a business specifications or business rules approach based on this book is glossing over the major surgery that would be needed to accomplish such a feat. Not only is the book dull and filled with indecipherable passages and a lot of fluff, the notation is weak. I recommend getting Tony Morgan's BUSINESS RULES AND INFORMATION SYSTEMS, which clearly explains what this book fails to, and uses the more standard UML as the notation language. If you still insist on getting this book, at least you've been warned.
Rating:
Summary: Excellent! No need to upgrade when a new tool appears.
Review: This book has some good ideas, but the author's inability to express them in a coherent manner hid them from all but the most persistent. What I liked about the book was the concepts and the attempt to develop a notation for expressing them. What I didn't like was the wordiness and inscrutabile writing style and the complete lack of reference to work done by Ronald G. Ross, which had a growing following. In addition, the unwillingness to use standard notation, like UML or even IDEF0, further relegated the good ideas in this book to obscurity. Reasons to consider alternatives:
* the book is conceptual, not actionable
* it's been overcome by business rules, which were in existence when it was written, but ignored by the author (or he was unaware of the existing work)
* poor writing ... I'm used to dry manuals, but this one is not only dry, but seems to be written by someone whose first language is not English. As noted by others this is not the author's fault, but his editors and the publisher. Get one of the "instead of" or "in addition to" recommended books and bypass this one.
Rating:
Summary: Too little, too muddled and too late
Review: This book has some good ideas, but the author's inability to express them in a coherent manner hid them from all but the most persistent. What I liked about the book was the concepts and the attempt to develop a notation for expressing them. What I didn't like was the wordiness and inscrutabile writing style and the complete lack of reference to work done by Ronald G. Ross, which had a growing following. In addition, the unwillingness to use standard notation, like UML or even IDEF0, further relegated the good ideas in this book to obscurity. Reasons to consider alternatives:
* the book is conceptual, not actionable
* it's been overcome by business rules, which were in existence when it was written, but ignored by the author (or he was unaware of the existing work)
* poor writing ... I'm used to dry manuals, but this one is not only dry, but seems to be written by someone whose first language is not English. As noted by others this is not the author's fault, but his editors and the publisher. Get one of the "instead of" or "in addition to" recommended books and bypass this one.
<< 1 >>
| 
