Here's (the paraphrased version of) a comment that I heard recently about the role of an architect that piqued my interest.
"being an architect is about ensuring separation of concerns using layering"
It's true that separation of concerns is a Good Thing because it increases your ability to reuse, substitute, maintain and test code at varying levels within the architecture. However, my take on this would be as follows.
"being an architect is about ensuring separation of concerns using layering where appropriate"
Introducing layers into an architecture is usually desirable for the reasons mentioned above, although there are times where additional layering can cause problems. Examples include increased complexity, a potential decrease in performance and something that's over-engineered for the job in hand. Choosing the number of layers to have in an architecture can sometimes be a tricky task. My advice is to take into account all of the other relevant factors (e.g. complexity, team experience, size of system, timescales, etc) and make a judgement call based upon all of them. No one size fits all.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.