An example that came up repeatedly during our working group meeting was the ``event-driven'' execution model. From our perspective, the choice that the overall application structure be based on an event-driven view of computation is a macro-architectural decision. The overall goal is to consider all subsystems within the application as ``stimulus-response'' objects that respond to specific events in particular ways. This is typical of a high-level, application-wide ``unifying vision'' that a software architect might use to achieve a consistent, coherent software design. This is also what most software engineers usually think of as software architecture.
To make such an event-driven application work in practice, concrete design decisions about how individual components interact with the event management code must be made. In particular, a specific software interface must be chosen through which all application-level components interact. Such an interface includes a definition of both the interface's syntactic and behavioral characteristics. Design decisions important to us at the micro-architectural level are whether (a) applications will register for particular events by providing specific callback functions to a central event manager (which in turn will take care of invoking the correct callbacks when events occur), or (b) components will poll for events, or (c) the event manager will simply invoke a single handle_event() operation on each component, delegating the responsibility of both watching for interesting events and dispatching the appropriate operations to the component. These choices are focused on the details of the actual interfaces of individual components or of identifiable subsets of all components. Any one could be made to work, but in order for the global vision of a ``plug-and-play'' event-driven application to be achieved, one choice must be made and then followed consistently.
By making certain commitments early, both macro- and micro-architectural decisions constrain some of the choices about individual component interfaces and may limit component generality. For example, an event-driven component from one application may be a poor fit if one tries to reuse it in another application with a top-down functional design. However, the purpose of architectural choices is to provide certain constraints that make reasoning about compositions of components --- how sets of components fit together, and how such composite structures behave --- easier and more effective for application designers. To the extent that the loss in flexibility actually buys an engineer greater understandability of an application, and buys the application structure itself greater configurability and adaptability, the corresponding architectural choices pay off in a tangible way.
Of course, high-level architectural decisions must be supported by low-level choices about component interfaces that actually ensure the composability, configurability, and adaptability properties that the software architect was trying to achieve. Architectural choices at both the micro and the macro levels depend on each other and provide mutual support. Essentially, they are complementary notions, and both are needed to effectively achieve the goals for which software architects strive.