If you were to ask anyone to describe "architecture" to you, nine times out of ten, they'll make some reference to structure. This is quite often in relation to a building or some other civil engineering structure, such as a bridge. Although other characteristics of these items exist, such as behavior, fitness-for-purpose, and even aesthetics, it is the structural characteristic that is the most familiar and the most-often mentioned.
It should not surprise you then that if you ask someone to describe the architecture of a software system he's working on, you'll probably be shown a diagram that shows the structural aspects of the system -- whether these aspects are architectural layers, components, or distribution nodes. Structure is indeed an essential characteristic of an architecture. The structural aspects of an architecture manifest themselves in many ways, and most definitions of architecture are deliberately vague as a result. A structural element can be a subsystem, a process, a library, a database, a computational node, a legacy system, an off-the-shelf product, and so on.
Many definitions of architecture also acknowledge not only the structural elements themselves, but also the composition of structural elements, their relationships (and any connectors needed to support these relationships), their interfaces, and their partitioning. Again, each of these elements can be provided in a variety of ways. For example, a connector could be a socket, be synchronous or asynchronous, be associated with a particular protocol, and so on.
An example of some structural elements is shown in Figure 1. This figure shows a UML class diagram containing some structural elements that represent an order processing system. Here we see three classes -- OrderEntry, CustomerManagement, and AccountManagement. The OrderEntry class is shown as depending on the CustomerManagement class and also the AccountManagement class.
Figure 1: UML class diagram showing structural elements