(focusing on a question “why signle out … SOA”)
I’d be delighted to dive in a deep conversation about the resoning. Instead let me pick just one argument: measuring. How does SOA implementation measure its success and reports it back to the business? Afterall many times it is comparable to changing foundation of a house – what builder or architect can do that without justifying it to the house owner? without showing metrics or any measurable facts after it is done?

When business asks IT “we need this new system” and allocates $$mln to make it happen, eventually in any healthy scenraio, that business (read: the requestor) is required to present justification (=metrics) how it is going to help the business and what’s the ROI.
Many SOA projects were initialized by IT side of the house with IT justification (if any) but very slim if any presentable value for the business. Not to mention that ROI and metrics associated with those projects were not made visible to the business after the delivery – which impacted an opinion that SOA is a big long cost that sometimes doesn’t even make it to production.
…and led to a general opinion that says: SOA does require business justification – it is not to single out SOA but rather to remind that SOA, the same as any other initiative in the enterprise; requires business justification.
(side note: Not all SOA implementations are as above – quite honestly there is a mixture, I myself have seen and participated in very smooth ones too; )
no matter how much we’ll defend or attack this opinion – it is a public opinion and public opnion is typically made by majority…

As I mentioned in the post, I understand the causes which led to the statement .. the same as what you talked about. The difficulty I have is the way the result gets articulated is a gross oversimplification which isn’t helpful.

For all the situations where technology considerations may have become more important than business, there are many (probably no fewer) where the reverse also is likely to have played out. And thats why I resent the A is more important than B. (I dislike that statement for any values of A and B). Architects understand architecture is about making technology work towards meeting business objectives no lesser than a person designing a Coke can manufacturing machine. But SOA seems to have this particular proclivity of attracting opinions which keep on talking about Business more important than Technology. I think we are in a world where technology continuously exposes, enables and delivers on newer and more creative capabilities, and the trick is in making them work together and the oversimplification risks the appropriate technology potential not being leveraged.

The intent or architecture is optimisation in a collective sense and not maximisation or suboptimisation in an individual sense. Its really like formulating a linear programming problem with an objective to optimise a goal (be it costs, revenues, headcount etc. etc.) around a number of constraints formulated using a number of parameters. Saying A is more important than B is like saying one of the parameters is more important than other – which I contest – its the “objective function” (in linear programming parlance” that is important. And thats the job architects are really supposed to perform.

When we start saying A is more than B, I have this nagging suspicion that more than architects are really starting to muddy the waters. Thats why I remind ourselves – we seem to have forgotten the A in SOA is Architecture.

>At the end of the day thats what architecture is. It is not about making one of business or technology more important than or subservient to other…
Any Architecture must be designed to serve a purpose (business goals), not to use a specific technology. Only under the construction the technology matters, after that, the technology matters just because it “serves the business goals”. Therefore the business goals should be more important during the design of the solution (architecture) that the technology itself.

>So if SOA stands for Service Oriented Architecture, then I must submit that architecture is the art of getting the two working together
That’s right, in fact “value over the other” does not mean reject, but the technology works to get the business goals…