Recently, ZDNet blogger Joe McKendrick posted about the shift from technology hype to advocacy for SOA: "corner office" versus "ground floor" SOA advocacy.
These aren't his words, but rather how SOA Consortium Executive Director Richard Soley differentiates between the CIO advocating for SOA to other C-level executives -- "corner office SOA," and the techies advocating for SOA to their counterparts in the lines of business -- "ground floor SOA."
It doesn't take an MBA to figure out which line of advocacy is going to be most productive. IT workers just aren't known for their successful advocacy within the lines of business. That's why CIOs spend so much time reading about IT/business alignment.
From everything I've read on techie blogs, at this point, "ground floor" advocacy would be better applied within the IT department itself. Most techies aren't sure what SOA precisely is, much less how to implement it or what changes it will bring in their day-to-day jobs.
Unless you're reading people who live and breath SOA, you don't have to read many blogs before you realize there's a lot of confusion over SOA among technology workers. Case in point: This recent blog post by an Australian IT worker with the revealing title, "CLARITY: Anyone understand SOA?"
Obviously, they aren't going to be great advocates for SOA yet.
The most popular reason for this lack of understanding is loose terminology. As blogger Jack van Hoof points out, even the common reference to "reusable" services is misleading. What's really meant is "shared services."
Reader Don Griffing recently took exception to one of this blog's titles, "Salesforce.com Introduces SOA as a Service." In an e-mail explaining his position, Griffing objected to what he sees as confusing marketing lingo being tacked onto a technology term:
My objection to the phrase "SOA as a Service" is attempting to combine computing architecture with marketing/sales model. It feels that the marketing folks at Salesforce.com are attempting to extend the wave of success with adoption/acceptance of SaaS by tacking "as a service" on their next innovation. Using the principles of SOA (Service-Oriented Architecture), they are now better able to extend their product offerings to applications that are not CRM-centric. However, tacking "as a Service" to the end of SOA causes the word "service" to be at the front and end of the phrase. This can only lead to confusion as the same word is being used with entirely two different meanings.
He differentiates between the utility services that we subscribe to - heating, water - and the term as used with SOA:
SOA (Service-Oriented Architecture) is an evolving set of standards and practices. In this term, "service" is being used to denote a set of articles for a particular use. This architecture will enable application developers to use the processing services that best suit their needs. This does not describe how the provider is to be compensated.
Griffing notes that we're still moving from a common understanding to a standard definition of SOA. I particularly liked that point, and think it's important to remember when reading or writing about SOA that there isn't a standard definition of what it is. Yes, we know it means service-oriented architecture, but for many, that phrase has no real meaning in and of itself.
If we're to move toward a real definition, Griffing argues - and I agree - we'll have to find a way to separate the sales pitch - and hype - from the real meaning:
Merging SOA with a marketing prepositional phrase will only lead to confusion in the business community. Ultimately, the term would be lost, leaving us grasping for another way to identify the concept.
Point taken. Unfortunately, it's pretty hard to do when you're working with something that isn't clearly defined. How do you throw out what it isn't, when no one can agree on what it is?
Sometimes, the best way to figure it out is to just do it. For those of you ready to jump in and work on a definition later, check out "Building a SOA" at SOA World Magazine. This piece is basically a project management outline for a SOA implementation. By walking through the steps to create a SOA, you start to get a clearer picture of what it is - and isn't.
And it just so happens to offer another option for SOA advocacy - actually doing a small SOA project or two. This is a great way to learn how SOA will work within your organization and provide a tangible demonstration of SOA's business value. Let's call it SOA advocacy for the real world.