Every discipline has a dominating activity or a guiding principle that dominates its practice. For example, if we take a snapshot of a Test Engineer's activity, we'll find that he or she is always trying to "break" the software. So we can say that a Test Engineer is always trying to break things as a general principle. Another example is a software programmer who's guiding principle is to always be looking for efficiency; how to use less memory, how to speed things up etc...
An architect's guiding principle or modus operandi is to Always Be Abstracting. To remember this, I use the three letter words ABA to package this principle in a portable way.
The main benefit of abstraction is that it simplifies complex systems and as a result of this simplification, the system can do more. I can safely say that all our advances in technology throughout history are a simple act of adding more layers of abstraction. Thus, we're able to do more and more. Take for example the OS, it abstracts the underlying hardware system so applications can do more. Then came the software libraries which added another layer of abstraction and allowed us to develop more powerful software faster. Then came the Microsoft .NET platform which added yet another layer of abstraction so we can deliver even more sophisticated systems.
What is driving abstraction then?
Two physical constraints: The first one and most important one is that the human brains can only handle a few concepts or entities at a time (they say seven). The second driving force is the embedded quality of the human being to keep "building" things, "improving" things and making thing more efficient and effective. That's a human's never ending quest since the cave man. So on one hand we have a limited capacity to hold in our brains a few concepts and on the other hand we have an unlimited flow of "needs". Something has to give: Abstraction is the only solution to allow for progress.
This is true throughout life and other disciplines other than software. For example, when we put a manager we're actually adding a layer of abstraction so we can simplify the functions of an organization and as a result, we can do more complex tasks. In the financial world, an investor is at the top of the food chain and probably in the highest levels of abstraction. On the other hand, probably an engineer or a technician are at the lower levels of abstraction. In the automotive world, a car brake pedal abstracts the details of stopping a car... Even the human brains abstracts functions by filing them in the short-term memory. That way it can do more complex tasks. Examples are riding a bicycle, driving etc... These are all functions that the brains "caches" and abstracts them in order to allow us to do more. Abstractions are all around us. I am sure you can think of a few.
Going back to the software world, we can safely say that a good software system is one where abstractions are well defined throughout. The well known Single Responsibility Principle (SRP) ties very well into that.
If we are always aware of abstraction as a principle, we can always make the software simpler to build and easier to implement more complex functionality and delivery more high quality capabilities. This applies to the full layer stack of a system down to the functions level. From the low granularity entry point service operations that abstract a use case or user goal to the workflow layer, to each of the components, it is a trickling down effect through layers of abstraction. This flow resembles more a pyramid structure then rectangles on top of each other. If you analyse closely, you have few components at the top "controllers" or "orchestrators" of the high level concepts and delegating to the relatively many "primitive" components that don't know much about the big picture upstairs but good at accomplishing a certain relatively lower level task.
So the key to human advancement in general as I demonstrated briefly is continuous abstraction. In the software world, which is becoming the foundation of most other worlds, abstraction is the job of a software architect. No pressure though.