Most application design or software engineering books will attempt some definition of architecture. The SUN study guide includes 1 from the RUP book, and another from the SUN SunTone methodology. You will find many others in the
literature.
Architecture is not always easy to define, especially in a short 'sound-bite'. I often find it helps to think in terms of levels of abstraction or 'focus'.
Architecture looks at the overall shape and form of the application - how the main parts interact. What are the underlying principles? Common services and components? How are messages passed through the system? How do clients interact with the core system? How is end-to-end security provided? etc.
Architecture is more often concerned with resolving the Non-functional requirements in the context of the overall problem.
Design is concerned more at the detailed implementation level - specific business rules, Use Case implementations etc. e.g. How can I store a CustomerOrder in a particular table? How do I update an Account balance?
Of course, in many cases these differences can blur. Architecture is still a design activity and there will inevitably be overlap - depending on the audience and the point of view (for example, the previous example of storing a CustomerOrder could be viewed as an architectural problem in terms of the wider object-relational mapping issues).
On your final questions - yes, system configurations, networks, servers etc are very much part of an architecture. They are often referred to as System Architecture, Network Architecture, Operational Architecture etc as opposed to Application Architecture (class design, iteration diagrams etc).
A good architect(s) should try consider all of these aspects. For example, a good application architecture should take into account the final system deployment (supported in UML via Deployment Diagrams). These real important for performance and failover strategies. Similarly, network configurations and distribution of components have real impacts on application design (especially when using inherently distributed technologies such as
EJB).
regards,
paul.
