Much of the commentary out there is regarding what I consider integration architecture. Topics like REST, Atom, XMPP, the dreaded WS-*, MQ Series, ESBs, application grids, etc.
You don't read as much about large application architecture. I think this is true because so much of the world today is dominated by integration. Most often teams don't have the opportunity to build something from scratch. Instead they are building things like web front ends to 30 year old mainframes. Things tend to get very fuzzy. You typically end up with a big ball of mud architecture.
I think the risk here is that there is indeed a difference.
Much of my time the last few months has been spent looking at building a new very large application. A large application has many different moving parts. This is similar to integration, but subtly different.
A key concept for me has been defending the core of the large application. XML everywhere makes zero sense in the core of a large application. Yet we see this in evolution strategies because different platforms are coming together (e.g., web and mainframe). Hammering a database on every page turn is bad - you have to be careful to seperate transient/active state from steady state/long lived storage. Also a large application needs to scale and is by definition then distributed. It can be very confusing.
For me, things like JavaSpaces and application grids make a lot of sense for large application architecture because they don't bork a large application into an integration effort.
But at least some of these technologies are also useful in an integration effort.
I realize that I am just blathering here. I think the only way to make sense of this is to separate the two concepts as best you can. The integration architecture should be the interfaces you expose and events you generate from various large applications or sub-systems. The application architecture should be dedicated to defending the conceptual integrity of that application / sub-system & pushing the integration to the edges.