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.
You are the first post. You can do it.
(-1, Raw and Uncut is the only way to read)
SOA = Service Oriented Architecture, and is one of the big crazes in the tech world right now.
http://en.wikipedia.org/wiki/Service-oriented_architecture
because the article didn't seem to help with that.
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
What is the weird fascination with "eastern" stuff among upper middle management? Virtually everything seems to have had a "zen" book written about it(because the "Zen of joining the rat race and being a driven type-A" is just so Zen.) and let's not even think about the number of besuited shmucks who think that reading a bunch of translated aphorisms about medieval Chinese warfar will make them a beast in the boardroom...
They're like Otaku with 401Ks.
A simple "No" would've sufficed.
What is this crap and why should I care? I have more books than I can possibly read in a lifetime and I would wager 90% of them have more meat on their bones than this book. This reminds me of the 90's schlocksellers like the Tao of Pooh and Physics which ruined the topics of both pooh and physics for years to come. Pastafarianism of Perl, now that is a book I would read.
By the way remember this
Circa 1999
You:
Oh, did you read they discovered the top quark at Fermilab?
Random Girl in bar:
No, what is a quark?
You:
{QED QCD explanations in a bar at 1 am. You know in your undergrad heart of hearts this is what women want to hear}
Random Girl in bar:
Sounds like Taoism to me. Have you read the Tao of Physics, it is a great book. It tells about how the Chinese knew about all that stuff thousands of years ago.
You:
What? No they didn't, the standard model of physics is not something that can be partitioned up into dualities for the purposes of serving some crackpot theory.
30 minutes later at home alone waiting for your dial up modem to get online so you can troll for porn on your isp's NNTP servers. Remember when ISP's had their own NNTP servers?
An Education is the Font of All Liberty
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.
"The present addiction to using initials instead of names and to giving institutions long titles that yield a pseudoword acronym is the childish-absurd."
- Jacques Barzun
We have created a Society of Acronyms, and are much the poorer for it.
Your brain is not a computer.
what's with this slapping zen on everything? What would the koan be : What is the spec before the meeting?
The real zen would be :
write simple, small things until the form is the function.
test in reality and in imagination, until both are one.
the SOA is the illusion. There is no SOA.
Nope, I still don't know what it is.
No sig today...
As someone who thought SOA would be a good thing (meaning SOAP and XML) I can say without a doubt it sucks.
I am working on IHE (Integrating the Healthcare Enterprise) (Electronic medical records sharing) and I hate it. We are constantly dealing with the same stupid problems time and time again: XML mismatches.
Please, anyone developing for the cloud or SOA use REST aka WOA (Web oriented architecture).
The difference is simple: Rather than use SOAP for everything, you match it to the usual HTTP paradigms (GET, POST, PUT, DELETE, with sensible URLs and HTTP headers).
The elimination of XML eliminates so many issues you will not believe. The best that I can tell is XML is a document, this document can be versioned, while HTTP is a protocol. You therefore eliminate a layer that has to be maintained.
For instance, the PirateBay uses REST-like inerface:
GET http://thepiratebay/browse/603 gives you the
whereas with SOAP you'd need to agree on a transaction name, XML schema, paramters. Then someone will decide that you need to support base64 encoded file uploads and downloads, so that'll have to go in the schema too. With REST you just use the standard HTTP headers...
Friends don't let friends develop SOAP.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
A monk once asked the Great Master Xideng of Xiangyan zi, "What is SOA?"
The master said, "The dragon song in the dried tree."
The monk said, "I don't understand."
The master said, "The eyeball in the skull."
The monk said, "I still don't understand."
The master said, "Yeah, me neither, I think its some crap they feed people who make too much money for doing too little thinking."
The monk was enlightened.
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.
You mean... like Unix?
(I was only an egg, but then I cracked)
(sample wisdom: study the office floorplan carefully. Identify the employees who sit in the corners of the room. Sack them first).
Damn, that's six potential business best-sellers straight away!
Eric Baird