Here's one concrete architecture/design smell that I encounter all the time: analysis and reporting directly from a transactional database.
This is certainly OK in some situations (i.e. light reports), but in many cases reporting and transactional processing requirements are in conflict. Yet, because it's the simple/inexpensive thing to do, reports are run directly off of the transactional DB. This causes all sorts of headaches on both sides of the equation.
This is typically seen in Enterprise LOB apps, btw. I understand that many SMBs just don't have the resources or know-how to create warehouses and datamarts (forget about cubes, or map-reduce setups), but many larger orgs that I've worked with have the same issues.
When designing a system, the architect really should be aware that reporting - especially analysis reports - and transactional requirements are best treated as separate issues and not just lumped together at the database level.