An anthropological view of SOA rituals
Summary: SOAers praise IT-business alignment; curse the 'Silos'
Remember reading "The Body Ritual Among the Nacirema" in your college sociology class? That's the paper that stepped back and coldly analyzed the bizarre cultural rituals among a strange tribe residing somewhere in North America. Of course, the tribe being analyzed was modern-day American (Nacerima backwards).
So, it is funny and eye-opening to read the observations of someone who wandered into the "SOA party" and make observations that put perspective on the SOA culture and the predictable rituals that have developed.
The rituals around SOA go something like this:
- "There are some things everyone seems to agree on.... The most prominent of these is 'SOA is not a technology.'”
- "This is often followed with a stern warning about how you can’t 'buy it,' it doesn’t come 'in a box.'"
- "There also seems to be consensus about SOA that it is about 'Business-IT alignment.'”
- "There is the ubiquitous prejudice (bordering on hatred) that SOA and its practitioners seem to universally hold against the poor beleaguered 'Silo.' (Oh Silo, who weeps for thee?)"
- "...to finish up the things everyone seems to agree on, it seems that SOA is definitely not JBOWS."
- "...Oh, and SOA is loosely coupled. It is definitely loosely coupled."
The author admitted feeling confused about what SOA really was, until coming across a metaphor for SOA "that finally made it click for me in a real way":
"SOA is technology, of course, and it is architecture, but it isn’t a style of architecture, like mud huts vs. Victorian mansions; it is a scope of architecture, like Building Design vs. Urban Planning. SOA is about turning ad hoc communities of software and process into an integrated economy composed of towns that are part of larger counties that are part of larger states, and so on. SOA is about the design and execution of the master plan, the infrastructure and government and laws that all of an organizations IT entities must follow to enable peaceful, productive commerce all around."
This metaphor, the author said, sure beats "trying to picture what 'driving increased strategic business agility and alignment into the enterprise' looks like in a way that can help you build it."
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
SOA is not a distinct level of architecture
No, it is not. It's not even necessarily *about* technology. One may apply SO principles to technology. One may apply SO principles to architecture. One may define an architecture for a technology project. But SOA isn't technology any more than city planning is building.
"...and it is architecture, but it isn?t a style of architecture, like mud huts vs. Victorian mansions; it is a scope of architecture, like Building Design vs. Urban Planning."
An SOA is not inherently a "city plan." Indeed, the SOA term started out life as more of a "building plan" concept. It was initially defined as an approach to application architecture, not enterpise or business architecture.
Architecture has differing scopes. High to low. Abstract to physical. Building architecture. City architecture. Service orientation is not a scope. SO is not confined to any particular level of abstraction. It is a style that guides how an architecture is created, at whatever scope one wants to create--it is equally applicable to application architecture as it is to enterprise architecture.
"SOA is about turning ad hoc communities of software and process into an integrated economy composed of towns that are part of larger counties that are part of larger states, and so on."
That's what "architecture" is. SO guides the segmentation and relationships of the components. SOA simply says one of the major components of the architecture are services (services are not the only components in a meaningful architecture).
"SOA is about the design and execution of the master plan, the infrastructure and government and laws that all of an organizations IT entities must follow to enable peaceful, productive commerce all around.?
This describes a business or enterprise architecture, which may or may not be service oriented. How the designs and the plans are formed is the SO part. SO is a way to approach A. And the A can be at any level of abstraction one wants.
SOA ~=~ SOAP
Reusable processes and SOA
Please see my post on this topic at -
http://virtually-works.blogspot.com/2008/06/reusable-processes-and-soa.html