There are many books and articles on architectural patterns available. Despite these, systems with bad architecture seem far more endemic than good architecture. Here's a quick taxonomy of the anti-patterns of architecture that I've spotted in systems over the last couple of years:

1. Catastrophe oriented architecture (or worst-case architecture) - a common anti-pattern that I've previously discussed in a Blog entry. This is where, rather than designing a system based on the current requirements, effort is focused on dealing with designing in support for the possible negative impacts that may occur, leading to a system designed as though every undesirable feature has been made into a requirement. For instance, designing a .NET application to be built in J#, and to only make use of Java compatible functionality, on the off chance that the enterprise strategy changes to a Java platform in the future.
2. Pattern oriented architecture - A trend that's found in systems created by architects who've recently read and digested books on architectural patterns and come to the conclusion that implementing patterns (such as front-controller, etc) is the key to a successful architecture. Rather than determining if common patterns are appropriate, and picking the most suitable one, all patterns that can be applied are done so, on top of one another, creating an entangled, schizophrenic system.
3. Enterprise oriented architecture - This is found in applications that sit within a larger Enterprise, where overly-engineered facets are put in place "for the sake of the Enterprise. For instance, using a data-center scale database server for logging exceptions as "it's the enterprise standard", or using an application framework that's larger than the application itself. The impact of this anti-pattern is the increased infrastructural cost and lowered agility of a system.
4. Interface oriented architecture - Noticeable by the number of interfaces in a system dwarfing the number of classes that actually implement them. This pattern regularly evolves for similar reasons to pattern oriented architecture, where certain more "advanced" features of systems (in this case interfaces), are thought to imbue quality into a system. A good example of this is a system where Customer and Employee both inherit from a base Person, even though there are no common functions in a system that could perform operations on both object-types.
5. Service dis-oriented architecture - Service dis-orientation is a recent anti-pattern that occurs when the technical principle of SOA gets introduced to an architect without the supporting body of knowledge. The principle, having communication via loosely-coupled Web services, is a technique that's useful in circumstances where distribution and interoperation are a requirement, but it also introduces many drawbacks (transactional incapability, for one). Service dis-orientation usually manifests itself as an architecture where internal objects or large datasets are exposed via the services, ignoring one of the key reasons for using them - abstracting the communication to that of business document, rather than the internal implementation.
6. XML oriented architecture - a design created by those that have jumped on the XML bandwagon and see it as a panacea to all. Systems designed using this anti-pattern are permeated by XML being passed through all layers - XML in the database, XML between layers, XML & XSLT for the presentation, generally resulting in an architecture with fairly loose tiering. XML is a great way of communicating between heterogeneous systems and represeting complex data structures, but, like every technology, it has its limitations. For instance, linking data and functionality is difficult with XML, as, potentially, is storing and manipulating it relationally.

I'll see if I can think of any more to add to this list as time goes on.  In the meantime, here's a question: Is it "antipattern" or "anti-pattern"?  The Google hit-count seems fairly even on the subject...