A software architecture begins as the result of the collective set of design choices made by the team that created the very first version of a system. These early beginnings, which might be sketches on a whiteboard or diagrams created in a notebook (or on a napkin), represent the intentions of this first development team. When the system is finished, these sketches may not represent reality, and often the only way the architecture can be explained is through a retrospective analysis that updates these initial designs to the delivered reality.
The initial version of a software architecture can be like a young child: whole and complete but immature and perhaps a bit unsteady. Over time, and through continued use and multiple release cycles, the architecture matures and solidifies, as both its users and its creators gain confidence in its capabilities while they understand and manage its limitations. The process is characterized by a commitment to obtaining honest feedback and responding to it by making the changes necessary for success. Of course, an immature architecture can remain immature and/or stagnate altogether without feedback. The biggest determinant is usually the market.
I've been fortunate to have been part of creating several new product architectures from scratch, and I've learned that the way architecture is actually created is a bit different from the recommendations of many books. These books tell us that when the system is completely new and the problem terrain is somewhat unfamiliar, designers should, for example, "explore alternative architectures to see what works best." This is sensible advice. It is also virtually useless.
There are many reasons that this advice is useless, but three of them dominate. Any one can be strong enough to prevent the exploration of alternatives, but all three are usually present at the same time, each working in its own way, sometimes in conjunction with the others, to motivate a different and more pragmatic approach to creating a software architecture. These forces are not "bad"they just are.
The first force is the lack of time in a commercial endeavor to truly explore alternatives. Time really is money, and unless the first version is an utter disaster, the team will almost certainly need to ship the result. They won't be able to wait! The strength of this force usually results in hiring practices that demand that the "architect" of the initial system have sufficient experience to make the right decisions without having to explore alternatives. In other words, hire someone who has already explored alternatives in a different job.
The second force, and one that is considerably stronger than the first, is the nature of the problem and its surrounding context, which dictate a relatively small set of sensible architectural choices. A high-volume, high-speed, Web site is going to have a relatively standard architecture. An operating system will have a slightly different but no less "standard" architecture. There probably isn't a lot of value in exploring radically different high-level architectures, although there is often some use in exploring alternatives for smaller, more focused, portions of it. These explorations should be guided by the true risks facing the project, and should be carefully designed to resolve them.
The third, and strongest force, is architectural "goodness," which can only be explored through actual use of the system. Until you put the architecture into the situation it was nominally designed to handle, you don't really know if it is the right one or even if it is a good one. This process takes time, usually many years .