The Zen of SOA 219
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.
First Lesson in writing a Review (Score:5, Insightful)
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!
Re:The Zen of First Post (Score:5, Insightful)
Re:SOA (Score:5, Insightful)
So it's a network with clients and servers on it?
Re:SOA (Score:4, Insightful)
It's a way to write procedural applications using Object Oriented languages, while still fooling yourself into thinking your system is Object Oriented.
Cue the flames from the zealots.
Re:The Zen of First Post (Score:5, Insightful)
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.
SOA? Ah.. Unix philosophy. Whats old is new again (Score:5, Insightful)
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.
Not a review, more of a brief summary (Score:4, Insightful)
Re:Eh Sonny? (Score:3, Insightful)
Re:Single provider and SOA? (Score:5, Insightful)
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.
Re:The Zen of First Post (Score:4, Insightful)
Zen of SOA / Art Of War (Score:3, Insightful)
I didn't see a section devoted to governance of SOA because without a strong IT Department your "Zen of SOA" will quickly become the "Art of Interdepartment War" as each division of the company will try to control or influence the service if they they have to connect to it. A strong IT Department can push back on the other departments for the greater good of the company and force departments with rogue apps to eventually use the services.
Re:SOA (Score:5, Insightful)
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.
Re:SOA (Score:3, Insightful)
It certainly does. It forces you to use procedural programming, and tricks people into thinking they aren't because the service boundaries are sometimes separated by a network and cross platforms; thus "justifying" the lack of OO.
Services provide and operate on data. The data itself is exchanged independent from the code/information needed to manipulate the data. This is exactly analogous to linking in a library to pass your data structures to. As opposed to the object oriented paradigm where the definition of operations are encapsulated with the data.
Service oriented architectures violate the very definition of Object Oriented design, and provide a convenient way to write procedural applications in Object Oriented languages. All while tricking the OO zealots into thinking they're still using OO.
All this time I though... (Score:4, Insightful)
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.
Re:The Zen of First Post (Score:3, Insightful)
It is also mandatory in DNS records. (look at your zone files in /var/named)
SOA = Start of Authority
it's the zone for which your name server is authoritative. It's usually tied to one of your net blocks.
Service Oriented Architecture is the correct answer here, though.
All these buzzwords kill me.
Re:Single provider and SOA? (Score:3, Insightful)
say your sole data provider is credit card payment system, or a database or whatever. The key is that if you wrap a data service round that source - and you map out business services such as:
Then if you get fed up with the provider of the credit card system then you have the chance to change suppliers without regression testing or rewriting any of the clients. Of course, it also works the other way around. Because you have a tightly defined *business* interface then you can add clients without having to regression test all the others and the backend system.
Clearly, you get the biggest benefit if you are a large organisation - the org I work at has 12m customers and 3500 staff with a history of many expensive silo'ed systems - so the systems are complex and varied. We have an SOA culture thats trangressed the crappy buzzwords and sales crap from IBM et al. Anyone who knows their stuff about enterprise IT should be doing this already.
Re:The Zen of First Post (Score:3, Insightful)
Service Oriented Architecture.
It's a software development design pattern that makes suggestions on how data, logic and responsibilities could be arranged in a distributed system.
The original and stated purpose of such acronyms is to give people a common vocabulary that makes it easier to talk about technology without dropping down to details every time. In reality SOA, like many of its relatives, has been immediately watered down to the point where the actual purpose becomes clear: To sell books, to blend decision makers with fancy tech speak on shiny powerpoint slides and, generally, to sound smart by dropping them randomly in meetings.
It falls into the same bucket as terms like "SCRUM", "Extreme Programming", "Agile", "Web2.0" etc. in that there is not "one" SOA with one ruleset or recipe to follow. Instead it's a generic tag that everybody and their dog uses to label their latest brainfart about distributed programming.
These tags serve an important purpose nonetheless; they are strong indicators for meaningless content and clueless people.
In that role they're real timesavers because whenever you encounter them in the wild you know that it's safe to stop reading/stop listening from that point onwards.
Acronym idiots (Score:1, Insightful)
What really bugs me about this article is the same thing I often see in technology - throwing around an acronym as if EVERYONE should know what you are talking about and isn't savvy if they don't.
You should ALWAYS spell out the acronym in the beginning of an article and then use the acronym as much as you want afterward. It's common courtesy and helps communicate your point to those who may not be wise to it. Sheesh!
Re:The Zen of First Post (Score:4, Insightful)
What you're calling a 'kit' I call 'unnecessary layers of abstraction' whether it's an application or yet another layer of management in an organization. From my perspective the number of software developers and executives that think another layer of abstraction is just the ticket has been growing exponentially for about a decade.
I blame books like this, and I blame java.
Re:As someone with an MBA and degree in CS.. (Score:2, Insightful)
ISO
"quality"
six-sigma
Total Quality Management
If you read through these, you will see tools and information on how to manage more effectively.
And if you don't see it, you should either get more experience or get your money back from Pheonix
No, I am not a Quality Manager. My experience has been in Manufacturing, Engineering, Research and Development, and IT Management.