I often find myself responsible for designing system architectures. This isn't an accident. I like figuring out the big picture that causes all the pieces of a system to fall into place. The better the architecture is, the more the answers to follow-on decisions (e..g, system boundaries, class hierarchies, internals APIs) seem self-evident. With a solid architecture, first-order features have elegant solutions that automatically extend to second-order features and system extensions.
The primary job of a system architect is to create the design, but a close second is to communicate it and facilitate its understanding and implementation. I think the primary key to successfully describing an architecture, whether for a solo effort or to a team, seems to be the succinctness of its description.
At their core, software development technologies seem to have followed a pretty straightforward trajectory. Each iteration provides a denser vocabulary that results in simpler system descriptions. By software development technologies, I mean the tools we use to express ideas. So, machine code gave way to assembly and then high-level languages. A high-level language lets us specify dozens of assembly instructions (hundreds of bits) in a single line. Modern languages reduce the number of tokens or lines of code we have to enter. C++ supports optional parameters and templatized functions and types. More modern languages allow syntactic and semantic elements to be optional--parentheses can be left off, type names inferred.
The trend seems to be continuing with things like C# incorporating data access as first order language constructs (i.e., LINQ), and platforms like Rails and Grails that rely on convention over specification. Each of these reduces the number of languages or the amount of code to be written.
In purely conceptual descriptions, above the language level, we have abstract data types and object-oriented methodologies, which allow us to describe domain models in terms of type names and operations, but even more importantly, they let us imply responsibilities and relationships between types. Describing something as a 'stack' or a 'queue' is sufficient to imply its operations as well as a large number of constraints on its behavior. Similarly, a well named element in a type hierarchy can imply all the richness of the domain object it models as well as the relationships the type has to other types. In a well-defined type system, simply the names of the types along with single sentence descriptions should be sufficient to communicate the bulk of the architecture. Design patterns jump us up another level, and let us refer to whole systems of types with short names (e.g., factory, composite) that are hugely dense in the information the communicate.
All cool, yeah, but why is any of this important? Because coding in the large is hard. The main challenge of writing a big system is to keep the large-scale design--it's principles, and patterns--in mind while simultaneously organizing class hierarchies and implementing well-formed loops. The denser the vocabulary for describing the high-level, the more room is left over in my head for other things. And there are always plenty of other things.