Sometimes, when my 5-year-old daughter wants attention, she'll start asking me questions. The why questions are actually the easiest because I can always look it up. "Why is the sky blue?" she'll ask. "I dunno," I answer. "Let's look it up on the Internet."
The stinker questions are the "what does X mean" questions. She'll start out with something broad, "What does blue mean?" And if I succeed in answering, she'll become more and more abstract, usually ending with something like, "What does 'is' mean?"
That's how it is with meaning. Sometimes, it's just not enough to define the term. To really understand, you've got to drill down and define the words used in the definition.
Dan Foody, VP of Actional Products at Progress Software, suggested recently this may be the problem with defining SOA.
Writing on Progress' SOA Infrastructure blog, Foody drilled down to examine what people mean by "architecture" when they talk about service-oriented architecture. He was inspired by a recent Sys-Con column by David Linthicum, who defined architecture as "the orderly creation, placement, configuration and management of IT assets."
That's a fine definition for enterprise architecture. But that's not the only way to define "architecture" in IT, Foody argued. Often, when people talk about architecture, they're actually referring to application or software architecture, he wrote. This type of architecture is defined by Wikipedia as "the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them."
The problem is, nothing about "SOA" clarifies which type of architecture you mean. Foody wrote:
"So, maybe we really need two terms: * Service-Oriented Enterprise Architecture (SOEA) * Service-Oriented Application Architecture (SOAA) Once you recognize this, a number of things start to fall in place. Both of these have value... but they are different."
Semantic conversations can get pretty darn tedious, but clearly, SOA still needs some clarification. And this isn't the first time I've heard it suggested that part of the problem may be related to too broadly using "SOA."
During a recent interview with Nick Gall, the Gartner analyst who coined the term Web-oriented architecture, he pointed out that there is a pretty consistent style of architecture that uses Web services and usually some middleware.
Many people call it SOA, but it's actually not technically SOA -- hence, the unending admonishments that "SOA isn't JBOWS" which means SOA isn't just a bunch of Web services. It's tricky, though, because while it isn't technically SOA, it could theoretically be used to build SOA, if it were loosely coupled. But it's usually not and, as it stands, this widely deployed approach has no name. Gartner's actually looking at how to name and classify this it.
My interview with Gall focused on the whole question of whether Web-oriented architecture is a subset of SOA or something altogether different. Gartner and Gall contend WOA is a substyle of SOA, as he explained in the interview.
I think Foody's post also speaks to why so many want to insist WOA is something new:
"Arguably, most enterprise architects think of SOEA and so the term SOA (at least among the purists) has drifted towards meaning SOEA. Unfortunately, this has alienated a lot of people, because a lot of people experience the value of SOAA every day (Web 2.0, SaaS, and cloud computing are great examples of SOAA but have little to do with SOEA) but don't think of it as SOA."
Unfortunately, clarifying definitions in IT circles is a bit like herding cats -- it's just about impossible to get everyone to agree on one direction. It's only slightly easier than defining "is" to a 5-year-old.