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
One question that recently cropped up is whether SOA makes any sense if you are only connecting with a single data provider? The idea being that the architectural and maintenance costs don't make sense in this scenario since there is just too much over heard. Once you have a requirement connecting to multiple data providers then the effort pays out. Just curious to hear what /.ers have to say.
Jumpstart the tartan drive.
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
So it's a buzzword based on more buzzwords. We're at buzzwords 2.0 now.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
You didn't tell me anything I couldn't skim in a bookstore. You've summarized each chapter into two sentences and said you recommend the book. Spend a little more time providing a critical evaluation - it would be helpful in getting people to decide whether to read the book.
it's a silver bullet!
it's awesome!
it's a great way to sell more hardware and app server licenses!
it's fantastic when you're a consultant because you can stretch out the billing time like you wouldn't believe!
"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.
... that SOA stood for Start Of Authority - as in the BIND name server configuration which inidcate that the config file is for a particular 'zone' (analogous to a domain name)
How disappointing to discover it something as loame as 'Service Oriented Architecture'. Tell me, do any of you have an architecture that is not 'Service Oriented', and if so, how do you use it, if your architecture isn't designed to accommodate/enable 'services' (i.e. functionality), what is its purpose.
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.
(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