If software architecture is about the structure of a software system, it's worth understanding what the major building blocks are and how they fit together at differing levels of abstraction.
The way that I like to think about this is as follows ... a software system is made up of a number of containers, which themselves are made up of a number of components, which in turn are implemented by one or more classes. It's a simple hierarchy of logical building blocks that can be used to model most software.
- Classes - for most of us, classes are the smallest building blocks of our software systems.
- Components - a component can be thought of as a logical grouping of one or more classes. For example, you may have an audit component that is made up of a number of collaborating classes. Or maybe you have an authentication service that is used by other components to determine whether access is permitted to a specific resource.
- Containers - a container represents something in which components are executed. This could be anything from a web or application server through to a rich client application or database. I tend to think of containers as executables that are started as a part of the overall system, but they don't have to be separate processes in their own right. For example, I treat Java EE web applications or .NET websites as separate containers even though they may actually be deployed and executed in the same process yet run in their own classloader/AppDomain. The key thing about understanding a software system from a containers perspective is that any inter-container collaboration is likely to be a significant remote interface.
- Systems - a system is the highest level of abstraction and represents something that delivers value to somebody, where a system is made up of a number of separate containers. Examples include a financial risk management system, an Internet banking system, a website and so on.
It's easy to see how we could take this further, by putting some very precise definitions behind each of the types of building block and by modelling the specifics of how they're related. But I'm not sure that's particularly useful because it would constrain and complicate what it is we're trying to achieve here, which is to simply understand the structure of a software system at a number of different levels of abstraction and describe the system with clarity at the right level of detail for the audience.