If ever there was an overused three-letter acronym, SOA would be it. Sadly few people that use the acronym actually understand what it really means. Managers think that it is the answer to all of their problems ("Let's just get one of those SOA things in"), and developers assume that it is just exposing everything as web services willy nilly. This book aims to cut through the hype and get to the truth behind the acronym.
Initially it seems that the book is targeted towards management types, but it soon becomes apparent that there is plenty in there for the technologists amongst us. Sure, there are no implementation examples, but this means that the book is able to concentrate on the real issues behind SOA rather than the Hello World examples that so many books turn to.
The book is told as the story of the IT sprawl that is Titan Insurance. Titan face the same problem as a lot of large IT organisations in that they have a lot of disparate systems that all need to work together to be effective. The book presents the case for creating an SOA based on Web services standards to achieve the integration, and presents many compelling arguments as the why this is the right way to go. The use of a recurring example through the book helps to give good context to the explanations which is something that is missing from so many IT books at this level.
As an architect trying to sell the SOA dream, this book presents "ready-canned" arguments that you can use, and plenty of technical information to back it up. This book explores both the technical and organisational issues behind SOA and is not afraid to highlight the parts of the puzzle that are not quite ready for the prime-time yet, and preempts most of the questions that people will typically ask you about SOA.
Rarely is an IT book a compelling read, but some how this book manages to be just that. I believe that I gained something from each and every chapter in this book. I think that the primary thing that I have learnt from this book is that employing an SOA is a great way to reduce coupling between systems (be they legacy or not) and also a good way to avoid the vendor lock-in associated with other EAI techniques. I also learnt that there is a fair way to go in some areas before this is an "easy" way to go, mainly regarding security.