This is generally a good thing, but architecture is important in all aspects of software and even the best SOA will likely fail without good underlying architectures in the implementation of the specific services. Oddly enough, the inverse is also true. The danger is that the effort and resources put into one architectural discipline will be for naught and may appear as failures if they are let down by the other.

I live in Chicago, a city known for its architecture. The city has fantastic architecture in its buildings and also in its infrastructure. Both are necessary for a successful city where people live and do business. The city is a success because the city planners designed and built great intra-building services (such as water, electricity, telecommunications and transportation) and because the building planners (architects) designed and built great individual buildings. Investing in either exclusively would result in a failure. Even the most fantastic building would be useless in a city without the underlying services that make success possible in the environment at large.

The same is true in the ecosystem that is the enterprise. Investing in architecture only at the level of the enterprise with SOA (the city) is only useful if the architecture of the individual components and services (buildings) are also appropriately designed and built. Inversely, investing exclusively in application architecture can result in missed opportunities in the context of SOA and very often in duplication of effort.

This occurred to me once when I was working with a large company. They had been doing truly impressive work on application architecture. Much effort was devoted to domain-driven design and Agile development. Within the application silos themselves, elegant and effective domain models had been designed to enable rapid and expressive programming to accomplish business goals. Unfortunately, the investment was underutilized once interaction was required outside of the application. Because of a combination of legacy technology and the unrelenting approach of deadlines, there was too much duplication. The carefully crafted domain models were at risk of being undermined since they weren't the sole conduit through which data originated and was persisted. The situation made it likely that the rug would be pulled out from beneath the applications.

Yet, this organization was ahead of the curve. As I said, they had very good application architecture practices in place. The only remaining work to do was extend these practices to the enterprise at the level of SOA.

I've been an application architect. I can definitely say that there can be an "us versus them" mentality in respect to SOA and application architecture groups. This can be due, in part, to the perceived proximity to both technology and business groups. It is a necessity that SOA is close to the business—more so than in traditional application architecture, where analysts and architects carefully tease out details from domain experts. SOA architects must be much closer and more subservient to the business at a higher and less personable level.

The "business" (as opposed to a department or line of business) can be difficult to conceptualize. This is only complicated by tendency for many developers to see these vague nonfunctional requirements often critical to successful SOA as fluff.

Many developers are used to being so close to the problem (and to the solution) that they think about it in the context of code. When faced with an immediate requirement, like "Read in and import this file," many developers and project managers don't appreciate the larger issue. What is happening here is the crossing of an intersystem boundary. This is even more pronounced when the source of said file is an external B2B party. Ultimately, this falls under the issue of SOA governance, but that's an article for another day.