Software Architecture plays a pivotal role in the delivery of successful software yet it’s frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the Software Architecture role exists on even the most agile of teams and is needed to produce well balanced software products and services that meet client's expectations and regulatory requirements.
One computer science guru put it this way, paraphrasing. "Anyone can build a dog house. And a cathedral is really just a gigantic dog house. So you build your cathedral and it collapses, because the more you scale something, the more architecture becomes more important than process. You can either then go learn sound architecture or pretend the collapsing building was the desired result."
This is not entirely true, as I've worked on projects with unsound architecture before and what usually happens is that instead of collapsing, a gigantic wooden beam gets propped up to support the cathedral from collapsing.
Except it gets in the way, so now you have to build around that gigantic protrusion, making any new additions to the cathedral take much longer than it should. Over time, more and more of these protrusions and add-ons and workarounds get tacked on, until even the most minor change involves navigating over a land-mine of bad choices and bad architecture, slowing any new development to a crawl.
When something is properly scaled and architectured out, adding new features is easy because the system is designed to scale. Since the goal of software development is to solve problems using software, proper architecture is about learning how to solve larger problems in a shorter amount of time.
Not only this is important, but another huge consequence/advantage of following best practices (either for architecture or smaller patterns) is related to the technical debt.
The more you follow best practices, the easier it is for a dew engineer onboarding the project to get it, understand how the pieces are articulated together, to look for a component where it logically should be, in short, to feel at home quick. From an engineering point of view, it enables the engineer to focus on what matter rather than digging in uncommon stuff, and becomes frustrated. As a bonus, being able to focus on the relevant stuff rather that trying to get how it has been built is less frustrating, which translate to a more productive developer... and in the long term, the engineer is less likely to quit and try to find a better project elsewhere.
From a business point of view, following software engineering best practices helps managing the velocity of the project. The less technical debt you have, thanks to these best practices, the more constant your feature development stays, and the more predictable your schedule can be.
This is a really short addition on the reasons why you should follow software architecture best practices, there's lots of conferences on the subject that are more educated that this small post ;-)
Séb