A review long overdue for a Jolt Award winner and one of the best architecture books on my bookshelf, Release-It!
I’ve recommended this book to many colleagues of mine and haven’t heard a disappointing review to date. I’ve heard the terms ‘pessimistic’ and ‘realistic’ used with equal frequency to describe this book. Having just completed my second reading, I can affirm that these terms are both representative take-aways. Nygard openly admits to being more than a bit paranoid about the way he approaches enterprise application architecture. Although this may seem alarming to many new to the IT field, those of us who have been around for a while recognize this as a necessary, at times life saving, defense mechanism.
Despite the presence of patterns, this is not really a pattern book that can be read piecemeal. It’s best read and enjoyed end-to-end. The books serves to teach us old dogs some new tricks as well as serving as a way to say “welcome to the field of enterprise application architecture” to team members new to this role.
- Real world production incidents, just in case you think: (a) you’re the only one who ever gets into such situations; or (b) such things don’t happen in the real world with large enterprise applications (where do you work?)
- The patterns. Even though there’s no sample code, the real value is in describing and cataloging these patterns.
- Organizational inconsistency. Two sections of the book (Stability and Capacity) follow the anti-pattern / pattern approach while the other sections of the book (General System Design and Operations) follow more of a narrative approach.
Yeah, the book focuses almost entirely on Java-based systems but almost all of the book has direct applicability to other enterprise technologies. In the last chapter of the book, Adaptation, Nygard’s writing style tends to wander a bit and deviate towards a rant. However, it’s hard to fault him for this, especially when he states things so eloquently:
Real enterprises are always messier than the enterprise architecture would ever admit. New technologies never quite fully supplant old ones. A mishmash of integration technologies will be found, from flat-file transfer with batch processing to publish/subscribe messaging. Any strategy formulated predicated on creating a monoculture—whether it is a single integration technology or a single programming language—is doomed to be a costly failure.