META Group, and others, long ago equated enterprise architecture with city planning. Each of the characteristics you mention, “autonomous nature,” “hierarchy,” “set of mandated conventions,” etc. describe typcial architecture aspects. The emphasis on those characteristics may vary from architecture to architecture certainly, but SO principles didn’t introduce these notions. They’ve been around a long time.

Yes. Business do that all the time. They might use Excel to track things, for example, but it’s hard to argue that the Excel part is a “service.” It is a tool, an “implementation detail” and is but a part of the service.

Steve Jones, in his book “Enterprise SOA Adoption Strategies” (free download at http://inforq.com/books/enterprise-soa), states:

“The objective of a service is to represent what the business does and place a boundary which all parties, but predominantly the business, can agree on. It is this representation of the business on which the createion of a Service Architecture must be focused, technology is very much a secondary element and many of the services will never even be realised using technology.”

Now Steve is firmly in the “SOA is a business architecture and technology SOA should be called SOD (service oriented design) or tSOA” camp. But it reinforces my point that SO can be applied at differing levels of scope and is not always about technology (though I understand that the conventional wisdom is that SOA is exactly about technology).

“Traditional architecture or generalized EA doesn’t mandate service autonomy or a common, enterprise wide infrastructure (or protocol), or centralized governance or loose coupling,…”

“Traditional architecture” or “EA” will mandate characteristics and constraints. The characteristics and constraints you’ve listed have appeared in non-SO architectures before. For example, EAI influenced architectures have touted loose coupling for a long, long time. Centralized governance is not unique to SO. The only relatively new thing SOA brings to the table, indeed, the *only* thing SOA specifies IMO, is that the major components are to be services whose implementations are separate from the interfaces.

SO principles do not, IMO, “mandate a common, enterprise wide infrastructure (or protocol).” SOA definitions, such as the OASIS Reference Model, generally do not specify how services interact/communicate. Just that they do. One may decide to define a particular architecture using a common, enterprise wide infrastructure, but that is not a necessity to be SO.

One can use direct, service-to-service communication. One could use mediation of some sort. Both approaches (and others) are equally valid and would be driven by other desirable architecture principles (such as those associated with EDA, for example).

“I can’t even picture what SOA could possibly be about if it isn’t about how units of business functionality as automated by software are expected to interact with one another.”

You’re right that typically SO efforts are focused on the things that are to be automated but not everything needs to be automated. SO principles can be applied (should be applied?) beyond just software.

Your view is that SOA starts and ends at an enterprise technology level (please correct me if I’ve mistated your view). Others have different views. My opinion is that SO can be applied at any level, with varying degrees of impact on the overall business. Clearly, SO applied to an application architecture is going to have fairly limited impact, especially compared to SO applied to business architecture, which is much broader in scope.

You touched on the higher level: it is “units of business functionality…interact[ing] with one another.” At a business scope, technology is not in the picture. As SO is applied to lower scopes that’s when the implementations get mapped to people, technology, software, etc.

“And I haven’t really heard of SOA being applied to application architecture,…”

Gartner is generally credited with formalizing the definition of SOA first:

“Service-oriented architecture (SOA) is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters).
SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces. SOA principles are rendered during application design, development and deployment.”

SOA initially was an application architecture notion. It has since been broadened in scope (some would say the term has been hijacked).

“I don’t see SOA as just a style, if scope isn’t involved then I’m totally missing the point. …”

That’s why we’re having this discussion.

“If it were just a style you can apply here and not there, ”

Exactly–I’d argue that 100% of the companies “doing” SOA are doing just that. They don’t apply it everywhere. It’s rather impractical, and as it happens, unnecessary.

“…then you could have one application handily crafted in the SOA style and one in the N-Tier style next door, ”

Hmmm. SO solutions are often N-tier.

“…but the connection between them isn’t addressed.”

SO solutions *must* somehow interact with non-SO components. Adaptive layers are typical.

“But then I don’t think you would have an SOA, as I have come to understand it. As I have come to understand it, the term SOA applies to all participants in a given system if they are N-tier or anything else.”

This is why I say “SOA is not a discrete level of architecture.” IMO, one should never say “we have an SOA.” Rather, saying our *business architecture*, our *enterprise architecture*, our *integration architecture* (SOA does not eliminate the need for integration), and so on, are service oriented is more appropriate.

Additionally, those architectures may be event driven, and implementations may be object oriented, etc. A meaningful, useful architecture will comprise more than just services and will employ more than just SO principles. Why refer to the architecture by just one of its characteristics?

IMO, SOA does not infer a particular scope (there are those that disagree with me, like Steve Jones, Anne Thomas Manes and others). It is the architecture levels we already had, like BA, EA, AA, IA, etc. that sets the scope. SO is applied to those.

In my mind, the city metaphor is not just “architecture in general”, or “enterprise architecture in general” whereas SO is a particular of flavor architecture in general. The important part of the city metaphor for me is the autonomous nature of each level in the systems hierarchy and that each logical entity transacts with those around it through a globally standardized infrastructure and set of mandated conventions that permeate the whole system, and yet a particular unit of logic, be it a web service or a LOB application, is as N-tier as it cares to be on its own time. Traditional architecture or generalized EA doesn’t mandate service autonomy or a common, enterprise wide infrastructure (or protocol), or centralized governance or loose coupling, but the city metaphor does imply those things, and from what i can tell those things are a pretty important part of most accounts of SOA I have seen.

I can’t even picture what SOA could possibly be about if it isn’t about how units of business functionality as automated by software are expected to interact with one another. Loose coupling, share contract not class, all that jazz is all about defining the relationships between such units of business functionality, and it standardizes that realtionship to maximize certain qualities such as reuse or loose coupling, and a standardized method of interactions to me feels a lot like how autonomous humans are similarly enabled to transact with one another in very complicated ways via a common set of laws, conventions and standardized infrastructure that is our society.

And I haven’t really heard of SOA being applied to application architecture, except in the context of composite applications, so I can’t speak to that, but I have a hard time picturing it. In any case I don’t see SOA as just a style, if scope isn’t involved then I’m totally missing the point. If it were just a style you can apply here and not there, then you could have one application handily crafted in the SOA style and one in the N-Tier style next door, but the connection between them isn’t addressed. You could say to a visitor “Here we have our ERP system, it was built using the post-WS-* SOA style. And here we have our CRM, it was constructed in the JBOWS style. I don’t recommend using that system at night, it isn’t in the best neighborhood” But then I don’t think you would have an SOA, as I have come to understand it. As I have come to understand it, the term SOA applies to all participants in a given system if they are N-tier or anything else.

I should’ve followed his link to here and commented, but instead I commented on McKendrick’s blog at http://talkback.zdnet.com/5208-10536-0.html?forumID=1&threadID=48368&messageID=902211&start=0

Summary: I disagree with the notion that SOA is a “scope” thing.