I have a really hard time with the idea that there is this thing called Architecture and it is separate from some other property or activity like Code/Coding.

I have a really hard time with the idea that there is this thing called Architecture and it is separate from some other property or activity like Code/Coding. If you show me the implementation of a low-level component (a file, class, namespace - depending on your design idioms and PL) in your system... basically, a set of functions/methods organized and composed into a whole -- then I can tell you if you have an Architect on your hands. For any business offering (any system/product line) the skill set required to factor this into a decoupled/maintainable whole is the same skillset required to compose a lower level subsystem or component. (Granted there is typically some knowledge/experience at the higher level system required --eg, around database systems/tradeoffs/theory, distributed system tools/properties/theory, etc -- but the core skillset of factoring is the same.) If you can't decouple a component into set of compose-able functions serving some component contract (I call this coding by the way), then you should not be trusted to compose an architecture for a system/offering. Similarly if you can do this decoupling at the low level and do it well, then you can do it at the higher level -- again, assuming you have experience and are familiar with the data structures typically found at those higher levels (queues, dbs, coordinators, stream processors, etc). There's a single fundamental skillset. It's the ability to instinctive decouple a system -- any system at any level -- into proper parts. One might say - well, an Architect is someone with this skillset. The non-Architects, the Juniors can be left to code up the smaller pieces, where problems stemming from their lack of skill can at least be marginalized. This is weakly true and a simplistic view, however. Because decisions made at lower levels can have permeating effects quite rapidly. Another way to put this is that as one problem-solves within an overall system architecture, one encounters novelty on the regular, so to speak. And the solution/s to this or that novelty has to be slotted first at the right level of the system... in one instant, you will find that the top-level systems need a slight adjustment to accommodate things, in another you'll find that nothing needs to be perturbed above the component at hand. If you say the Junior needs to tap the Architect's shoulder in each such instance, then you'll find quickly that this is pointless and the Architect would do better to write some code. You either have people with the skillset or you don't. If the skillset is there, the architecture will be organically established. If the skillset is absent, whether you have an Architect in title bears less on the technical quality of your system but you may get a win on the team/organizational side of things.