Slashdot Mirror
The Zen of SOA
Alex Roussekov writes "The book "Zen of SOA" by Tom Termini introduces an original view to the challenging world of SOA. He refers to the Zen philosophy as a "therapeutic device" helping SOA practitioners to get rid of prejudices and opinions in order to apply a clear mind-set based on real-life experiences and the application of technology knowledge. Each chapter of the book is prefaced by Zen Truism that the author suggests to "revisit, reflect on it longer, and see if you are able to establish a truth from the narrative, as well as from your own experiences." In fact, the book is about a SOA Blueprint outlining a methodology for building a successful SOA strategy. The target audience is C-level Executives, IT Managers and Enterprise Architects undertaking or intending to undertake adoption of SOA throughout their organizations. I strongly recommend the book to all SOA practitioners involved in implementation of SOA." Read below for the rest of Alexander's review.
The Zen of SOA
author
Tom Termini
pages
112
publisher
BlueDog Ltd (November 21, 2008)
rating
9/10
reviewer
Alexander Roussekov
ISBN
ISBN 978-0-615-24703-8
summary
provides a clear methodology to guide SOA implementations
The author's vision is based on extensive experience in the SOA arena and he elegantly leads and prepares the reader for the introduction of his SOA Blueprint approach. I personally enjoyed reflecting on the Zen conundrums which stimulated me to focus and understand the content.
In Chapter 1 the author explains SOA as both Business and Technical Concept and the main challenges it tackles from different stakeholder perspectives. He also emphasizes some misconceptions and technology myths about Web Services and ESB which are key enablers but do not represent a holistic view of SOA.
Chapter 2 elaborates on using the SOA Best Practices as a critical success factor for maximizing an organization's potential and improving performance. The author recommends an Incremental Approach to the SOA Implementation. This is supported by a comprehensive Case Study with the US Federal Trade Commission client.
Chapter 3 gives a technology view of SOA. The author covers a number of SOA technology components, their capabilities and positioning within the SOA technology stack including Portal, ESB, Service Registry/Repository, Business Rules and Enterprise Search Engines.
In Chapter 4 — the concept of "Future-Proof" is defined by the author and his team as "architecting to be highly available, reliable, and easy to manage."
The future-proofing is an inherent quality factor with technological and cultural aspects which need to be achieved throughout the overall SOA Lifecycle. The author suggests that "a pilot, or proof-of-concept, presented in advance of implementation and deployment, can convincingly demonstrate the ability of the architecture to validate the business intent".
Chapter 5 presents the author's rationale for an incremental approach to SOA implementation. The main point is that the contemporary business dynamic creates a myriad of competitive pressures which impose significant risks, whereas an incremental approach shields the business from the SOA implementation demands and helps to accommodate the changes and utilize the benefits.
Chapter 6 "The SOA Blueprint" is the essence of the book. It is a "set of guidelines for the practical business deployment of services using SOA methods in a moderately sized, somewhat complex organization". The author has used the OASIS' reference models for SOA as a foundation framework. The Blueprint is also consistent with well defined and recognized methodologies such as TOGAF and Zachman. For example, the Blueprint artifacts fit well in the taxonomy of the Zachman Architectural Framework and they can be mapped to corresponding activities in the TOGAF ADM.
Chapter 7 provides practical guidance and recommendations related to the context of the SOA Blueprint. The author puts the focus on Standardization, Business Customer Perspective of Services, Risk Mitigation Strategy as well as technical aspects such as Data Integration, Service Orchestration, Security and Metadata.
Finally, Chapter 8 offers a checklist with a number of items required for the customization of the SOA Blueprint. The author provides both item definitions and procedural guidance.
Tom Termini shares deep expertise and knowledge gained by hard work on numerous SOA projects for government and private sector clients. His examples of real business value achieved can be traced in the case studies described in the book. Each case study is related to a particular SOA "koan" and comes with the description of the business context, approach, solution and the business benefits obtained as a result.
The Zen of SOA is a concise, readable and very well illustrated book which provides practical advice, guidance and immediate impetus for development of SOA Implementation Strategy, Vision, Roadmap.
You can purchase The Zen of SOA from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The author's vision is based on extensive experience in the SOA arena and he elegantly leads and prepares the reader for the introduction of his SOA Blueprint approach. I personally enjoyed reflecting on the Zen conundrums which stimulated me to focus and understand the content.
In Chapter 1 the author explains SOA as both Business and Technical Concept and the main challenges it tackles from different stakeholder perspectives. He also emphasizes some misconceptions and technology myths about Web Services and ESB which are key enablers but do not represent a holistic view of SOA.
Chapter 2 elaborates on using the SOA Best Practices as a critical success factor for maximizing an organization's potential and improving performance. The author recommends an Incremental Approach to the SOA Implementation. This is supported by a comprehensive Case Study with the US Federal Trade Commission client.
Chapter 3 gives a technology view of SOA. The author covers a number of SOA technology components, their capabilities and positioning within the SOA technology stack including Portal, ESB, Service Registry/Repository, Business Rules and Enterprise Search Engines.
In Chapter 4 — the concept of "Future-Proof" is defined by the author and his team as "architecting to be highly available, reliable, and easy to manage."
The future-proofing is an inherent quality factor with technological and cultural aspects which need to be achieved throughout the overall SOA Lifecycle. The author suggests that "a pilot, or proof-of-concept, presented in advance of implementation and deployment, can convincingly demonstrate the ability of the architecture to validate the business intent".
Chapter 5 presents the author's rationale for an incremental approach to SOA implementation. The main point is that the contemporary business dynamic creates a myriad of competitive pressures which impose significant risks, whereas an incremental approach shields the business from the SOA implementation demands and helps to accommodate the changes and utilize the benefits.
Chapter 6 "The SOA Blueprint" is the essence of the book. It is a "set of guidelines for the practical business deployment of services using SOA methods in a moderately sized, somewhat complex organization". The author has used the OASIS' reference models for SOA as a foundation framework. The Blueprint is also consistent with well defined and recognized methodologies such as TOGAF and Zachman. For example, the Blueprint artifacts fit well in the taxonomy of the Zachman Architectural Framework and they can be mapped to corresponding activities in the TOGAF ADM.
Chapter 7 provides practical guidance and recommendations related to the context of the SOA Blueprint. The author puts the focus on Standardization, Business Customer Perspective of Services, Risk Mitigation Strategy as well as technical aspects such as Data Integration, Service Orchestration, Security and Metadata.
Finally, Chapter 8 offers a checklist with a number of items required for the customization of the SOA Blueprint. The author provides both item definitions and procedural guidance.
Tom Termini shares deep expertise and knowledge gained by hard work on numerous SOA projects for government and private sector clients. His examples of real business value achieved can be traced in the case studies described in the book. Each case study is related to a particular SOA "koan" and comes with the description of the business context, approach, solution and the business benefits obtained as a result.
The Zen of SOA is a concise, readable and very well illustrated book which provides practical advice, guidance and immediate impetus for development of SOA Implementation Strategy, Vision, Roadmap.
You can purchase The Zen of SOA from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
If there is an acronym that you are going to use throughout your review, and it will be senseless without THEN DEFINE IT SOMEWHERE AT THE TOP!
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Hmm, a book titled with a buzzword contains more useless buzzwords, jargon, and trite case studies. No wonder why the reviewer states that it's made for C-level officers and other PHB's.
So it's a network with clients and servers on it?
I read the internet for the articles.
Gosh it would have been nice if someone had defined SOA in the actual posting, and maybe put in a sentence or two on what it's all about. Just throw a bone to those of us not "in the know".
I'm reminded of a former employee of where I work who used the most esoteric and abbreviated language possible, and then showed utter contempt towards those who asked him to clarify.
I was reading the SOA wiki page wonder what the hell they were blabbering about. Then I got it.
It's the old Unix ideal of having many small tools each doing a small job well, and being able to easily tie those tools together into chains (or dare I say pipes) to achieve results.
Except now instead of it being simple, there are committees, XML schemas, and trade shows. This will help it's success by allowing high priced consultants to participate.
- For the complete works of Shakespeare: cat
One question that recently cropped up is whether SOA makes any sense if you are only connecting with a single data provider?
You have a single data provider now. Will you rewrite the program from scratch when you add another? Will you "rework" it to accommodate the second? Or will you man up and design the thing from scratch as extensible and reusable?
This is the same architectural argument that's cropped up in the discipline since assembler v. compiler.
Hell, farther back than that. Eli Whitney's great innovation, not always recalled, was interchangeable components in firearms. Before that, every weapon was crafted from muzzle to buttplate as one unique system. But try to find an off-the-shelf replacement for the frizzen. Sorry, no can do.
But Whitney's flintlocks? Drop a big pile of mixed components on the table. I guarantee that as long as there's one of each part in the pile, you will be able to assemble a working rifle. Need a carbine? We'll make up a shorter barrel which is still compatible with the receiver and the stock. Converting to percussion cap? No problem, the entire lock mechanism is an engineered replaceable unit.
That's what SOA aims at: interchangeable components in systems. You're not crafting one big program, or complex of programs, from end-to-end, making it up as you go. You're building uniformly-structured and interchangeable components, and assembling them.
Yeah, it's cheaper to build stovepipe. It's just more expensive to use, maintain, and replace.
The folks who argue against these enterprise architecture innovations are the gunsmiths late 18th Century: each thing they turn out is a work of mastercraft, unique and tightly coupled, but entirely constrained by the human limitations on their ability, vision, and skill. But a rifle buyer isn't buying a work of art; he is buying a functional artifact, and if it can be engineered to function better (or differently, if the need arises) by no longer treating gunsmithy as a craft and more as an engineering discipline, so much the better. The artiste gunsmith may be offended. But too bad.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Ah, so it's a way to sell more machines to run more infrastructure software (also sold) which companies think will increase their scalability, which they don't really need because most of them are never going to have the amount of business that would force them to scale, where simple client-server software would suffice while they're going down the tubes.
That is all.