Thanks for including some of my thoughts in your article Michael. There are a 
couple of points that I'd like to elaborate.

--- In [email protected], Gervas Douglas 
<gervas.doug...@...> wrote:
>
> 
> 
 
> In the comments to the Anne's post, Rob outlined that IT reached 
> the stage where isolated individual "SOA initiative" (that I 
> called 'SOA projects' ) 

My reference to "SOA initiative" was in the context of what I perceived to be 
presented by Anne (and others) as an enterprise-wide effort, not an individual, 
less-than-enterprise-scope project effort (which I may have misconstrued). But 
the thought remains the same regardless of scope--SOA is the wrong thing upon 
which to focus.

> have demonstrated their incapability to reach the value of 
> service-oriented solution in "/organically growing SOA/", i.e. SOA 
> must be treated at the enterprise level to be productive and should 
> be driven by the Business.

I fear that some of my wording may have led to a misperception of my viewpoint. 
I have never stated nor will I ever intentionally say that "SOA must be treated 
at the enterprise level." I've tried to be consistent in the view that SO 
principles can be applied at any scope. In my view, SOA is not inherently an 
enterprise concern. SO principles are a great fit in an EA but that's not the 
only place.

If by "driven by the Business" you mean driven by non-IT groups/people, I also 
take issue. If by "driven by the Business" you mean driven by business 
objectives, goals and priorities (however and by whomever those are 
established) then we agree. Architectures should be driven by business 
objectives, goals and priorities. The person that is the champion of that might 
come from any organizational unit. It's the skillset and the business objective 
focus that is important, not where they are in the org chart.

> I usually promote similar approach to *SOA *explaining it as *a 
> business-oriented consumer-centric architectural model*. *Any 
> violations of mentioned characteristics lead to SOA failure*. 

+1.

> Anne's response was a bit unexpected: "/Given that the business 
> (i.e., non-IT people) rarely gets involved in system architecture 
< design, it doesn't really make sense to argue that SOA should be 
> driven by the business. 

Which simply means people in IT need to pay attention to business objectives, 
goals and priorities. "Business driven" can mean a focus on these aspects 
rather than "spearheaded by someone in a non-IT group."

> SOA is an IT architectural style. IT people are responsible 
> for designing the architecture of the IT systems. Hence, SOA must 
> be driven by IT. BUT: IT *should* direct its SOA initiative based 
> on business requirements/." 

All efforts should be based on business requirements. SOA isn't unique in this.

> The essence of my position is that *business 
> requirements derived from non-service oriented business 
> implementation* (i.e. business operational processes) *kill SOA in 
> IT*; does not matter what IT does, SOS is not needed for such 
> requirements.

An interesting thought. Let's see if I understand what you're saying. As an 
example, you contend that for an EA to be successful in following SO principles 
that the BA that drives it must also be SO. Steve Jones promotes this as the 
best way to approach things since there is a natural mapping between the two.

You're saying that SO needs to be applied top-to-bottom to be successful. I'm 
not so sure (though I have no evidence one way or the other).

-Rob

Reply via email to