The past few days I've been cataloging several hundred architectural and design patterns (you'll need to be logged in to the Handbook to follow that link). A metapattern is emerging, with a number of clusters of related patterns becoming obvious. It's a little early to say so definitively, but my current hypothesis is that groupings of these clusters can be aligned along each of the views in Philippe's 4+1 model view; in other words, there are logical patterns, process patterns, implementation patterns, deployment patterns, and use case patterns.
Most of the patterns I've cataloged thus far are solidly design patterns, meaning that they represent some named society of classes or components that interact. Some of the patterns I've studied are classified by their authors as architectural patterns, but I'm rapidly coming to the conclusion that that's the wrong name for this genre: they are in every case really a pattern associated with one view of a system, not its entire architecture (although they are larger than a society). I'm not sure what to call them.
The other issue I'm wrestling with is the distinction between an architectural pattern and an architectural style. We don't yet have a lot of good named instances of either, although we seem to be able to smell them when they are nearby. For example, "Web-centric" is a candidate style, for it implies a collection of interlocking view-specific patterns (in terms of deployment, it's a classic distributed system involving application servers; in terms of components, it involves static components such as HTML, dynamic ones such as DHTML, and operational ones such as beans and relational databases; logically, there are a plethora of design patterns commonly at play). DoDAF is another candidate style. Or is it an architectural pattern? Perhaps it simply a documentation standard? One can argue effectively for each of these positions.
By the way, this very issue is one that a working group of the IASA is tackling right now, in its metamodel work.
It seems all too often in our industry we chase a methodology by starting with some broad ideas and deducing instances. What I'm trying to do here is the reverse, working inductively by starting with the instances and identifying the underlying general principles.