Architecture is a widely-used term within software development yet is very hard to define rigorously. Indeed, it changes meaning from domain to domain, company to company, project to project and even from employee to employee.
The term "architecture" must be disambiguated from that of domains other than software. For example, the building industry is the natural home of the title "architect", so much so that local laws can restrict its use to certified or accredited professionals in that industry. The intent of such restrictions is usually to prevent someone fraudulently representing themselves as sufficiently skilled to design a building but has, on occasion, led to criticism of software professionals for stealing the term1.
A simplistic view of architecture is to consider why it exists: architecture is one of the means by which your project's requirements are met.
Of course there are numerous aspects of software development that contribute to the requirements being met. Architecture provides structure to the development, improving the control so the project can be delivered with greater certainty. Architecture also draws on industry best practice and creates a blueprint for implementation to reduce the risk and cost inherent in the project.
Architecture achieves many of its goals using what is often referred to as "design". It's therefore important to understand what "design" is and how it relates to architecture.
As a noun, design is the named (although sometimes unnamable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions). [Grady Booch]
While certainly not definitive, Booch's succinct description does highlight some of the key features of design.
Firstly, the design exists to resolve a force on the system. Forces can be the cost, scope, resources, timescales, requirements - anything you wish to take into consideration as part of your design selection. This is to say that the design should have a purpose. As we'll see, this is an important aspect of software architecture.
Secondly, a design is one of a number of possible choices for resolving a particular force on the system. Making the right choice is naturally important, especially if the architecture is to resolve the forces on the system effectively and without introducing too many of its own.
Design is not peculiar to architecture, though. There are forces on all aspects of software development and deliberate means for resolving them. We therefore need to consider how design relates to architecture. Again, Grady Booch provides a good starting point.
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. [Grady Booch]
So perhaps we can conclude that architectural design decisions are only separated from other design decisions by how expensive a mistake would be. Therefore architecture requires more experienced, more rigorous selection to avoid these potentially costly mistakes.
To summarise, consider the following definition of architecture:
Architecture is simply the deliberate and considered resolution of significant problems.
It is still subjective, relying on a local appreciation of what is significant to your system. However, it does highlight the need for architecture to concern itself with the more significant problems - typically measured by the apparent or perceived cost of change. By coming to understand those things that are architecturally significant this definition becomes more tangible; the rest of our book provides numerous examples of those concerns that may qualify as architecturally significant so hopefully you'll be able to achieve some clarity as to what "significant" means with respect to this definition.
This also highlights the need for architecture to be intentional, at least as an activity. While all systems have an architecture, if you are to undertake the role of an architect it is not sufficient simply to capture that system's architecture post-hoc.
1 It would seem that the main reason for the criticism is that it makes it hard for architects in the building trade to search for information and jobs online rather than software architects attempting to ply a trade designing buildings.