Service-Oriented Modeling: Service Analysis, Design, and Architecture

My initial review was written in a hurry and consequently was extremely brief, i.e. "Provides some good techniques for modeling SOA architectures. Unfortunately, other than an extension to the UML, to my *knowledge* there is not yet a standard modeling symbology or method."Honestly, this book is a great effort at creating a candidate modeling standard for SOA, and an alternative to IBMs SOA modeling techniques. I have been through the "modeling wars", such as the handful of variations, and a dozen weird alternatives, to the "structured techniques" pioneered by Ed Yourdan, and Chris Gane & Trish Sarson, (built on previous works by Michael Jackson, Peter Chen, and others.) As the UML was introduced in the 1990s as a modern, OO based, conglomeration of these techniques, it was both (a) a great effort at creating a common analysis & design "language", (b) a bit more complex and hence confusing that it needed to be(!), (c) a standard that many tool vendors supported (and that MicroSoft, in a odd instance of brilliance, supported(!) in VISIO).BUT - at the turn of the century, just as the UML was becoming more commonplace, SOA concepts were being introduced, and yet no common modeling standard was introduced. Clever architects used a combination of UML models and "layer" diagrams to document SOA based systems, but for the most part the IT industry had to play catch-up to define some form of standard that could be applied across projects, companies, and industries.Michael Bell's book does a great job of proposing a standard for documenting SOA architectures, supported by real-world examples. Most of my experience in the last 10 years has been that architects "wing-it" with their personal modeling standards, although most at least have a vertical or horizontal (the best included both!) "layering" model. The problem with the layering model is that it is essentially a "context" and does not cover the details of the services themselves. That is where Michael Bell's book provides a useful pattern that can be used to communicate to --stakehodlers, --business analysts, --designers, --programmers,--testers, --project managers and others involved in the typical IT project.When I am in a leadership position, and my architects do not have a reasonable SOA modeling standard of their own, I will be using this book as a reference for them to base their models on.

I have purchased and read many SOA books and they have all fallen into one of 2 camps. They are usually either "HOW-TO" implement a SOAP/XML/WSDL based request response guides with the standard buzzwords of SOA Governance, WS-*Everything and the Kitchen Sink*, and of course a vague description of how an Enterprise Service Bus magically does away with years a poorly implemented legacy systems. This is the first SOA book that I have read that did not waste my time with page after page trivial XML examples but actually presented an entire working formal language(extended or inspired by the UML component model I believe) to describe your existing environment("As-Is") and future-state architecture in everday terms understandable by business users and application developers. I'll admit when I read that the approach is both 'Holistic' and 'Anthropomorphic' I felt like I was being marketed some Ginko-Biloba pseudo mysticism but as I read through I understood that this is an approach to SOA, probably the first, to actually make the the underlying services and consolidation of services visible and tanglible in the way an architect builds a scale model of a proposed structure to provide an in depth understanding of the project to those who are unable to turn equations into 3D structures in there heads(which is most of us). The authors crowning achievement, in my opinon, is the realization that everything (Legacy System, Schedule Batch Job, Business Apporval Process, Business Rules, Storage) must be treated as 'Services' is a quantum leap for SOA that moves the concept of SOA from a vague buzzword to a concrete deliverable, tangible item.

The author seems to have some interesting notions about what services are and how to discover/model them starting with the business. I like this business-oriented focus, which avoids much of the bias towards "everything as a SOAP web service connected by ESB". The truth is, as the author suggests, that we need to model services in a heterogeneous fashion because that is the reality we as architects live in.Where the book goes off the rails is in its prose. Concepts are hard to sieve out from overly wordy sentences that tend to obfuscate whatever the author is trying to convey.I found myself becoming increasingly frustrated the further along I read, often trying figure out what the book was trying to tell me. Looking at the diagrams more often than not made things no better because I couldn't understand what they were trying to convey, either.I believe there are kernels of goodness, if not greatness, in this book. I plan on presenting the ideas to my colleagues in the coming months. I only wish the task was easier and I believe a second edition with better editing would result in a book that is crisp, concise and roughly half the number of pages.