The authors of "Service Oriented Architecture for Dummies" are partners of Hurwitz & Associates, an information technology consulting firm. They provide a high-level overview of service oriented architecture (SOA). SOA breaks with traditional practices of software development, which frequently led to the creation of many redundant "siloed" data stores and applications across the enterprise, by promoting the development of reusable services that can be strung together in different ways to achieve multiple ends.
A key thesis of "Service Oriented Architecture for Dummies" is that successful transition to a service oriented architecture (SOA) requires the cooperation of business managers and I.T. people. SOA is not simply the latest and greatest approach to building distributed systems; SOA also re-conceives how business and I.T. should work in partnership to construct their software architecture. The authors warn that simply asking developers to design a set of reusable services may not result in the creation of the right sort of services. Developers need instead to work in close cooperation with businesspeople to make sure that the services being developed serve useful business purposes. This is sage advice that evidently comes from long experience consulting on I.T. projects.
That SOA is still a developing design philosophy becomes evident as the authors discuss some of its more advanced dimensions. The authors make a good case, for example, that as SOA evolves it will become necessary to guarantee certain levels of service and it will also be necessary to implement SOA supervisors to monitor the overall quality of service. However, they caution that most enterprises have not made it far enough along the road to worry about such things. It's also interesting to note that while they recommend setting up formal repositories and registries for services (using UDDI, for example), most of the companies in their case studies section are still using excel spreadsheets, web pages, and the like. The lack of implementation gives some of the authors' best practices a slight air of speculation. However, the authors repeatedly make the point that the best way to achieve SOA is not to turn everything into a service at once, but to begin with a key service and then iteratively develop new services as the value of having such services is recognized. Enterprises may implement the more advanced aspects of SOA down the line as the number of services grow and the complexity of their interaction increases.
The chief drawback to "Service Oriented Architecture for Dummies" is its aim to speak simultaneously to developers and businesspeople. The authors were almost apologetic for including a section titled "Nitty-Gritty SOA," which covered XML, SOAP, WSDL, UDDI, etc. They clearly did not want to put off their business readers by introducing too much technical jargon. However, this unwillingness to get into too much technical detail proved frustrating at times because some key topics lacked any detailed technical exposition. For example, the authors emphasize again and again the importance of having an enterprise service bus (ESB) but failed to provide a satisfying explanation of how precisely an ESB works to orchestrate services at a technical level. I also could have done without the quick listings of various vendors' offerings in SOA in Part V, although the accompanying case studies were valuable. I imagine that the majority of this book's readers will be software architects who will appreciate having this kind of high-level overview to use as a touchstone for discussion both with developers and business managers.
"Service Oriented Architecture for Dummies" successfully makes the case that transition to a SOA will generally result in lower development costs, fewer redundancies across the enterprise, faster response times to market changes, and the development of more creative kinds of business services. It may provide just the kind of reassurance that many I.T. and business folk need to get started with SOA at their own companies.