I’d like to start this review by stating I’m a big fan of the Dummies books. The light and humorous style helps make the information they present very easy to digest. SOA for Dummies achieves this tone. I admire the clever chapter and section titles such as “Noah’s Architecture”, “I never metadata I didn’t like” or “Talkin ‘bout My Federation”. It also presents the business concepts and benefits clearly. It’s written well, and enjoyable to read. This, and the strength of the Dummies brand, has made it the #1 SOA book on Amazon.
But the problem is, there are quite a number technical confusions and inaccuracies in the book. For example, in the SOA architecture diagram they have a service broker connecting to an enterprise service bus. This confused me, because what is an ESB if not a broker? It routes messages to services based on content, polices, and rules. It is functionally equivalent to a message broker, and some vendors renamed their message broker an ESB. In fact, some vendors claim the ESB is a pattern, not a technology, and claim a number offerings that are functionally equivalent. But the essential function an ESB provides is brokering requests and responses between services.
But their definition of a Service Broker is “software that brings components together by using the rules associated with each component.” (p. 339). That didn’t mean much to me so I went back and read each description of a Service Broker. In fact, I think they are talking about orchestration – not brokering. Because the component services in a SOA are loosely coupled, there needs to be something that defines the flow of control. Orchestration and choreography are the generally used terms in the industry to describe this. There is also confusion as to what the difference between the two is, and it would have been helpful if they authors addressed the issue. Instead they confused the issue more by using a term that is generally use to describe a different set of functionality.
There is also a danger that readers may come away more confused than enlightened when reading about BPM. The authors present a diagram of a Process Manager (p. 58) that includes a SOA Registry, a Workflow Engine, and a Service Broker. While, BPM is very complementary to SOA, it is a separate and distinct technology and does not require SOA. The term BPM itself is inherently confusing. It can mean either Business Process Modeling or Business Process Management. While the authors mention this in passing, they seem to use the term interchangeably, citing a modeling tool as one of the early business process management solutions. The diagram of a BPM tool (p. 53) shows the BPM tool programming a workflow engine, creating business functions, and linking to business applications.
To clear up a major technical inaccuracy represented in this diagram, BPM tools automate processes and can initiate business services, but do NOT create business services (as depicted in the diagram). While many BPM tools have the capability of wrapping processes as Web services, the diagram depicted looked like automation of the process from the model included creating services.
For the sake of clarity (and helping readers understand process management options and technologies), I think it’s helpful to make the distinction between different types of processes. There are automated processes and human centric processes. Many in the industry use the term workflow to refer to human centric processes. Different tools on the market focus on different types of processes. Different features and functions are required for each. For example, human workflow tools require browser interfaces for assigning and managing work, such as load balancing when someone is out and work needs to be redistributed. Tools designed to automate process tools are also very good designing and implementing the end to end business process as a composite application calling multiple services. BPM tools deliver the added benefit of management (the M in BPM) which service choreography tools do not. The authors do not even touch on business process monitoring, management, and dashboards, and how they increase the business value of SOA, something which they otherwise discuss at length.
The chapter on adapters (Chapter 7) starts with the statement “Adapters make SOA possible. No adapters, no SOA – it’s as simple as that”. This statement is just not true. The authors fail to make the distinction between an adapter and an interface. An application programming interface (API) is essentially a set of function calls. Most packaged applications have their own proprietary APIs. Some legacy applications don’t have any APIs, which is why legacy integration is so challenging. Without adapters, the developer must master many different APIs to enable communication between applications. Adapters simply the task by providing a common set of function calls to different applications.
WSDL is a standard interface, not an adapter. Web services provide a common standardized way to call services and are a key enabler for SOA adoption. I suppose it is a matter of semantics to say that wrapping an application with a WSDL interface is creating a SOA adapter, but a native Web service does not require an adapter. In fact, Web services obviate the need for adapters. It is true that as organizations evolve their SOA adapters will continue to be used to integrate existing applications. But over time, Web service interfaces will replace the need for adapters.
While the authors make the book very user friendly by separating out the “plumbing” from the other concepts, the problem is when they finally do get around to talking about the plumbing more confusion arises. The layered architecture picture (p. 121) shows a Business Services Layer, The Plumbing Layer, and the Hardware Layer. First of all, it is an extremely simplified view of SOA. There are many more software layers, and multiple layers of service granularity (this is not addressed at all in the book – but maybe that is too detailed for a Dummies book). The items listed in the Plumbing Layer include: “Mobile Computing, Desktop Management, Patch Management, Service Desk (this one is particularly puzzling – why isn’t it a business service?), Systems Management, Network Management, IT Asset Management, License Management, Provisioning, Performance, Scheduling, Configuration Management, Storage Management, Database Management, Back-up/Recovery Services, Archiving, IT Security”. The thing is that most large organizations already have all of these in place as part of their enterprise architecture. I was confused as to what it was supposed to depict as it is certainly not the SOA plumbing. The diagram fails to list any of the plumbing technologies that ARE relevant to SOA including ESB, registry and repository, data translation, transformation, aggregation and integration, process automation and management, event processing engines, rules engines, BAM, etc. Maybe they think they already covered SOA technologies in the architecture picture in the front of the book.
Another potential area of confusion is the SOA Supervisor, later described (p. 126) as the component that monitors the business processes and manages SLAs. As the authors explain it, the SOA broker informs the SOA Supervisor when a process is initiated, and the SOA Supervisor consults the registry to “get the details of the full business process so it can set up monitoring software to monitor all the necessary components”. The term and description were very confusing because there is no product on the market called a SOA Supervisor – it is not a term generally used in the industry. The examples they give of SOA Supervisors are HP’s OpenView SOA Manager, Amberpoint’s SOA Management System, and Progress Software’s Looking Glass. These are runtime management tools. But the authors put the SOA Supervisor in the middle of everything, as if it is the traffic cop. While I would agree that runtime management is very important to ensuring governance policies are being met, the architectural depiction makes it look like it is running the whole show. Again, confusing.
There are other examples, but you get the idea. While weak on the technical detail, the book does do a good job in presenting the overall idea of SOA in a very readable manner. When the discussion is on a high level the book excels. The discussion on SOA and Federation (p. 71) and SLAs (p. 188) are very good. But overall, this book would have benefited greatly from a much more rigorous peer review before publication. It promotes a web site containing updates, which would be very helpful – if it existed, which it does not.
Wily has generously offered ebizQ copies of the book which we planned to feature on our site and in our upcoming SOA in Action conference. But my concern is should we promote it to an unsuspecting public when it contains so many important inaccuracies?
What do you think we should do? Have you read the book? Would you like to and provide an alternative review? How about if we start a SOA Intelligence Wiki? Would that be something that would interest you? Looking forward to hearing from you on this one.
Perhaps you might start by talking with Judith Hurwitz and the folks at Hurwitz group about your misgivings. If you have OK. It is difficult to write about a moving target.
I am approaching this question from a somewhat different perspective than I suspect most of your readers may have; that of an educator (in a business school) who, for four years, has been attemping to move our various IS/IT curricula towards service/process thinking and doing. The existing professional books on SOA, BPM, etc. are generally unsuited for student use, lacking problems, questions, short cases, and the other materials that might engage a novice student. And, in general, they are very technical. Of what's out there I prefer Erl's and Khoshafian's books; albeit for different reasons. And, of course, some of Peter Fingar's books for motivation and level-setting.
I attended IBM's recent IMPACT conference where SOA for Dummies was heavily featured, and so I decided to buy it. Not withstanding the legitimate issues raised by Ms. Gold-Bernstein, the book is, at least an approachable, readable thome but doubtless reflects one or a few vendors "adaptation" of the now-vague terms (courtesy of the marketing machines): ESB, SOA, BPM(S), and the like.
So, I would like to second the call for a Wiki-based approach to not only SOA but also the related areas such as BPM, EDA/BAM, and so forth as a more democratic approach to defining and explaining what these concepts and their use is all about. That said, I have no idea how to avoid a replication of what goes on in the standards committees of OASIS, W3C, etc. where a few vendors dominate and if they don't like where things are headed they shop at the next standards door.
As a final comment, I'll offer that there is a whole movement around developing for-free Wiki books across variety of subjects. The general, altuistic motivation for this is to provide learning resources to less-developed countries (e.g. www.wikibooks.org).
My $0.02.
Richard W.
Richard, thank you very much for your $.02. Think it's actually more valuable than that. I agree an approachable book is very helpful in the market. That's probably why the book is doing well. Just hate to see readers walk away more confused.
BTW - I have shared my comments with the publisher and the authors, and I have invited them to comment back on this blog.
I would second the concern to support a book with so many inconsistencies. EbizQ stands as a place to get authoritative information and folks might assume then that if you promote it the book is good. Wiki solution seems to solve not only this immediate problem but a much larger problem as reflected above.
I am currently working on a SOA book for managers. It would be good to have a panel for reviewers from here for my book. If anyone is interested is please contact me ASAP.
Regards
Atul
Atul how to contact you ?
Posted by Jennifer Webb for the SOA For Dummies authors, who tried several times to post.
he SOA for Dummies book has been a tremendous success, not just in sales through shops and Amazon but because major IT vendors have been distributing it as the best available text to explain SOA. The material presented in this book was discussed and reviewed with over one hundred people representing major SOA vendors, SOA consul-tancies, and end-use customers. Many of these discussions have been in the form of healthy debate on all issues related to SOA which is, of course, are ongoing as organi-zations gain additional experience with this approach. We have been very pleased with the positive response to the book. Nevertheless, as is clear from the review posted here, by Beth Gold-Bernstein, it has at least one or two detractors. Unfortunately the re-view is flawed.
Proclaiming that there are many technical inaccuracies, she (the reviewer) boldly claims that representing an ESB with a service broker on a diagram is somehow technically inaccurate. But it isn’t. In some situations the service broker function could be included within the ESB, but this isn’t always the case. Many of the early SOA implementations we are aware of didn’t use an ESB (there weren’t many around). They tended to be built using a home grown broking mechanism and a home-grown registry in a hub and spoke arrangement.
Even today we still run into architects (some working for major IT vendors) who believe that an ESB is unnecessary. Some suggest that the enthusiasm for ESBs is generated by middleware vendors who are repurposing their software and marketing it as a neces-sary component for SOA. For example, we recently witnessed a project where the de-velopment team built their own broker for the prototype and then implemented an ESB (with the knowledge that if the ESB didn’t perform or never delivered enough benefit they could ditch it).
However, it is also the case that a large SOA implementation can lead to a heavy amount of message traffic and having an ESB to manage messaging and carry out the broking function is an option, depending on the product. Like many product-based terms in IT, ESB is not well defined, something made abundantly clear when the reviewer re-marks that “some vendors claim that an ESB is a pattern”. The reviewer is most likely referring to IBM, but IBM’s use of this term is IBM-specific - its patterns are components that can be used to deliver software solutions in particular areas - something that is not clear at all in the review.
The reviewer also takes issue with the depiction of Business Process Management (BPM) in the book. This is mostly haggling about terminology (BPM is another product-based term). She seems to think that BPM does not require SOA. Initially BPM was a separate development - an evolution of workflow and it actually didn’t require SOA until it embraced web services as reusable components. Nowadays though you’d be hard pressed to find anyone who thinks the two are separate. Indeed, the reviewer changes her mind about this a few paragraphs later when she declares how business process monitoring, management, and dashboards increase the business value of SOA. How do they do that if they don’t even require SOA?
She next weighs in on adapters. The book states “no SOA, no adapters” a fact that she seems to think incorrect. I suspect that her mistake here simply comes from a lack of knowledge. She seems to think that the only function of an adapter is to provide an in-terface. She even describes WSDL as a standard interface, whereas it is a definition language for describing interfaces. Adapters are however hook-up points between com-ponents and you can include much more in an adapter than calls. You can add services in. Taking the definition of an adapter from http://www.enterprise-soa.com “In the con-text of an SOA an adapter is an intermediary service that bridges incompatible data formats between services and its clients. An adapter often also acts as a façade or technology gateway.” Indeed. In particular, an adapter may implement an intermediate security service or embody response time monitoring services. The reviewer is quite wrong.
She has a problem with the use of the term “plumbing” which is used throughout the book to refer to system management services in an effort not to have to discuss their relationship to SOA in any depth. Unfortunately within SOA there are many unsolved problems in this area and there are few products that connect a SOA with the wide vari-ety of management services that are needed to manage corporate applications.
For the sake of simplification we made the “SOA supervisor” the connecting link be-tween the plumbing and SOA itself. We didn’t invent the idea of the SOA supervisor we simply extrapolated it from products that are early attempts at approaching the problem. Some hoped-for capabilities, such as automated resource provisioning and global opti-mization of resources cannot be achieved without such a component. Neither can there be any automation of system management services, because ultimately they can only derive from service level monitoring.
When I first read this review I couldn’t make up my mind whether it was a genuine cri-tique, or a deliberate hatchet job. Although clearly inaccurate in a number of areas it presents one or two useful perspectives. It’s a shame - the review would have undoubt-edly profited from the editorial oversight of someone who was better versed in SOA than its author. As one of the authors of SOA for Dummies, I would have appreciated that.
Robin Bloor, co-author SOA for Dummies, responding for the SOA for Dummies team