Part is just experience. You have to have seen enough different kinds of people and systems work together to understand what works and what does not. I think a

Part is just experience. You have to have seen enough different kinds of people and systems work together to understand what works and what does not. I think another part is simply nomenclature. There's a joke about the only two hard problems in computer science: Cache expiry and naming things. It's a joke because cache expiry reduces to naming the keys correctly if you do it right. Basically, if the different parts of the system don't have sensible names that represent what they actually do (and that there are, indeed, different parts of the system), then there's an architecture problem. You have to have an effective metaphor for the way that you want the system to work, and the problems you want each part of it to solve, or nobody will be able to understand the entire thing. I run into this often. People have a functional but struggling system designed with the "big ball of mud" pattern, where you just keep slapping gobs of code onto it until it does what you need, and then they want someone to come in and "do architecture" at it. This predictably fails. So, there's your heuristic: if it has good names, and the pieces do what they say on the tin, you're on the right path. When something starts to have responsibilities that aren't under that name, you should move those responsibilities somewhere else and name them appropriately. Edit: There's also a second-order level where you start to recognize the way that cross-cutting concerns happen in different areas and design a piece of the system to handle that concern in an organized way. You can probably think of a bunch yourself, but an easy example you want to handle earlier rather than later is logging, and another significant one is authentication