This morning, the SOA Consortium (my client) released a podcast of David Butler’s SOA Transformation talk from our Ottawa meeting. I posted about it on SOA Consortium Insights and Business-Driven Architect.
Shortly after, Mark Griffin of Greylines posed some excellent points / questions in the comments of BDA:
“I may be being a bit to cynical about this, been a long week already. But having a technology vendor say its not about the technology is about the same as when I hear Exxon say it’s looking for alternatives to oil. I question the motive. 🙂
Still this point comes up a lot in the discussion about SOA. I think it deserves a bit more attention as a whole beyond the SOA is about the business type of discussions. My opinion has been all business software development is about the business. Why is this perceived to be different?
I see the differences in design from a software point of view. It is quite different than what a lot of shops are use to. But IT-Business alignment has been a topic of conversation and a goal of IT for a while now. How does a service orientation change that on-going conversation with the business?”
While I did respond (at length) in the comment section, I wanted to call out the conversation here, and invite others to jump in. My reply:
“Mark, Excellent questions / points. Not cynical at all.
On the “SOA is not about the technology”, please note that was me dragging out my soapbox as a leap from David’s “business-oriented architecture” comment. For your first question, I think Exxon is looking for oil alternatives so they have something to sell in the future. Following that scarce commodity line of thinking, you could say software vendors want someone to sell to in the future.
I think the larger, multi-purpose (“strategic”) vendors understand that the “sell and forget” business model doesn’t make for sustainable customer relationships. For these vendors, their best interest (motivation) is to ensure customers actually attain value from software investments. This means admitting to and assisting with the hard parts of technology adoption – organizational change, process and people. Note I did include “assisting with” because these same multi-purpose vendors also have services organizations. (More motivation)
As for the business focus, I couldn’t agree with your statement more “My opinion has been all business software development is about the business.” Unfortunately, when “SOA the marketing label” burst onto the scene, the conversation was all about products, protocols, acronyms and religious fervor. That hype cycle told business folks they needn’t care about SOA, it was an IT thing.
Of course, those of us that were employing “SOA the approach” knew better. That SOA is a viable strategy for business-IT alignment, because [soapbox warning] defining, employing and composing business services, in business interactions, business processes & event processing, allows IT to deliver solutions that actually match the intent and operations of the business. However, IT can’t do that alone. IT & the business need to collaborate on defining services that align with business capability. But there is that troublesome “SOA is an IT thing” obstacle.
So, long comment longer, we need to reclaim / re-orient the mainstream SOA conversation away from bits and bytes to delivering business capability. And then, actually deliver the promised and expected capability.”
Oh, and in full “conversation disclosure”, last week as I was reviewing the recording, I tweeted excerpts including “SOA is a business-oriented architecture”, which Dion Hinchcliffe augmented as follows:
[Disclosure: HP is not a client of my company, Elemental Links, but is a founding sponsor of the SOA Consortium, which is an Elemental Links’ client.]
