An architecture defines coherent groupings of related elements that address a given set of concerns. For example, an architecture for an order processing system may have defined groupings of elements for order entry, account management, customer management, fulfillment, integrations with external systems, persistency, and security.
Each of these groupings may require different skill sets. It therefore makes perfect sense to align software development team structures with the architecture once it has been defined. However, it is often the case that the architecture is influenced by the initial team structure and not vice versa. This is a pitfall that is best avoided, since the result is typically a less-than-ideal architecture. "Conway's Law" states that "If you have four groups working on a compiler, you'll get a 4-pass compiler." In practice, we often unintentionally create architectures that reflect the organization creating the architecture.
However, it is also true to say that this somewhat idealized view is not always practical since, for purely pragmatic reasons, the current team structure and the skills available represent a very real constraint on what is possible and the architect must take this into account.