Are there architecture smells?

Question

There are tons of resources on the web referring to and listing code smells. However, I've never seen information on architectural smells. Is this defined somewhere, and is there a list available? Has any formal research been done into architecture defects, and their impact on project speed, defects, and the like?

Edit: I wasn't really looking for a list in the answers, but documentation (on the web or in a book) about architecture smells.

Answer 1

• Multitier Architecture When you have Layers on Layers on Layers on Layers... you see my point here, in your application. I call it Over Layered Architecture
• Over abstraction in such way that you get lost in the code.
• Futuristic Architecture This happens when the solution is too futuristic. In reality no one can predict new requirements. Therefore most of the futuristic implementation is just waste of time and resource.
• Technology Enthusiastic Architecture The architect liked the new technology and he put in production. Without knowing if it was proven before.
• Over Kill Architecture A simple problem was solved by exponential factor of architecture skills and technology.
• Cloud Architecture I call it cloud architecture since architecture has no connection to the really. It’s just some nice Visio diagrams.

The total lack of the opposite is also true.

Here is link of Top Ten Software Architecture Mistakes.

Answer 2

Everything is Configurable. When an architect tells you that his system is change-proof or highly-customizable because of extensive configurability, that's an architecture smell.

The problem is that you can really only provide configuration mechanisms for what you think right now is going to need to be configured, but once your application is in the wild, it will not be sufficient. Then, the configuration mechanisms expand and expand, and eventually you get the Inner Platform Effect.

And then you are in software hell.

Answer 3

A database designed by an ORM! Or a database backend that is nonrelational that should be relational. Or a database where you design to use views that call views that call views, not only are they too slow (databases must be designed for performance from the start not later) but when you need to make a change, they are horrible to track through (Over abstraction as @AmirResaei said makes it easy to get lost in the code when you need to fix something that is at the bottom of all those layers.)

Answer 4

Code smells and architectural smells are one and the same. Code begins to "smell" because of sub-optimal architecture.

In Martin Fowler's seminal book on the topic, Refactoring, he presents a series of Code Smells and identifies way to refactor them out of your system. Joshua Kerievsky's Refactoring to Patterns further emphasizes this idea by giving specific architectural patterns to fix various code smells (and how to refactor to them step by step).

Most refactoring is done to alleviate suboptimal code via enhanced architecture. One could argue that the only naturally born "Architectural Smell" (other than Big Ball of Mud), would be the BDUF (Big Design Up Front) Architecture. Where you try to accommodate everything you need before the first line of code is written. An agile software project where design is done as needed (even I daresay where code is treated as design), will have its architecture grow organically.

Answer 5

(A lot of) Coupling -in whatever form- is what makes architectures smell. The more it's coupled, the more it smells.

That said : no coupling at all often smells performance issues.

Answer 6

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.

Answer 7

I'm not sure if this rightfully fits at the architecture level, but if I see a bunch of manager classes/modules in what is supposed to be an OO design then that is a guarantee that the only person who will understand the architecture/design is the architect/designer himself without lots of explanation/learning by others.

Answer 8

There are many architecture smells documented by the community. A commonly occurring set is the following.

• Cyclic Dependency: This smell arises when two or more architecture components depend on each other directly or indirectly.
• Unstable Dependency: This smell arises when a component depends on other components that are less stable than itself.
• God Component: This smell occurs when a component is excessively large either in the terms of LOC or number of classes.
• Feature Concentration: This smell occurs when a component realizes more than one architectural concern/feature.
• Scattered Functionality: This smell arises when multiple components are responsible for realizing the same high-level concern.
• Dense Structure: This smell arises when components have excessive and dense dependencies without any particular structure.

I recently prepared a taxonomy of smells. Currently, it documents 38 architecture smells and more than 260 total code smells.