Conversation on "SOA as Business-Oriented Architecture"

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.]

Comments

[Jack van Hoof]

Looking from the business side, there is the composition of business activities into autonomous business functions. These functions offer services to each other and communicate - preferably - events based to obtain their autonomy. Such a business service could easily be outsourced without any disruption of the overall business process. Such a business service can also easily be delivered (shared) to different business contexts (internal or external). I call this the Service Oriented Enterprise. This has nothing to do with IT.

On the other hand there is the composition of application constructs. The top level of such a construct preferably maps with an autonomous business function. Current standards based technologies make it possible for IT to support events based interaction between the autonomous business functions, which in turn boosts the Service Oriented Enterprise.

So SOA is about business and at least equally about technology. If not more, because a good technology oriented SOA will even offer benefits to a lousy organized non-SOA business. The way around - non-SOA technology supporting a business oriented SOA - is hardly thinkable...

If you want to travel from A to B, cars and asphalt ARE relevant. If you don't recognize the IT-perspective you are missing 75% of your sight on SOA. Why are some so strongly turning their back to enabling technologies when we talk about SOA? From a technology perspective SOA is able to support even the most lousy business processes. It might be delightful to view SOA from that perspective as well.

-Jack
http://soa-eda.blogspot.com>http://soa-eda.blogspot.com