There still exists a common misconception that "architecture" and "agile" are competing forces, there being a conflict between them. This simply isn’t the case though. On the contrary, a good software architecture enables agility, helping you embrace and implement change; whether from changes in requirements, business processes, mergers, etc. What is considered a "good architecture" is still up for debate of course but, for me anyway, the core characteristics of a good architecture relate to good modularity reached through an appropriate decomposition strategy. If you've experienced the pain of making a major change to an existing big ball of mud, where seemingly unconnected parts of the codebase break, then you'll appreciate that having a well structured codebase (good modularity) is important.
A big problem I see with teams today is that they adopt, what George Fairbanks calls in his Just Enough Software Architecture book, "architecture indifferent design." In other words, they adopt an architectural style without necessarily considering the trade-offs. In today's world, this is commonly manifested in teams adopting a microservices architectural style simply as a reaction to their existing monolithic codebase being considered a mess. Jokes about these same teams subsequently creating a "distributed big ball of mud" to one side, it turns out that the process of software design and decomposition is hugely important, irrespective of whether you're building a monolithic or a microservices architecture. You don't get agility or a good architecture for free. Some conscious design effort is needed and trade-offs need to be considered. This, again, is why creating that starting point with some up front design is crucially important.
