Definition: An architectural model is a rich and rigorous diagram, creating using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem.  We use architectural models to communicate with others and seek peer feedback.

Let's look at that definition a little:

• rich - for the topic you are describing, there should be sufficient information to describe the area in detail.  The information should not be lacking or vague.  Your goal is to minimize misunderstandings, not perpetuate them.  This can be taken too far, of course.  See my notes below on 'primary concern.'
• rigorous - you have applied a specific methodology to create this particular model, and the resulting model 'looks' a particular way.  Here's the test of rigorousness: If two architects, in different cities, were describing the same thing, the resulting diagrams would be nearly identical (with the possible exception of visual layout, to a point).
• diagram - I know that many folks will use the word "model" to refer to any abstraction that simplifies something for the sake of addressing a particular viewpoint.  I find that definition to be useful, but I'm specifically subclassing it to architectural diagrams.  In my humble opinion, if you cannot draw a picture to communicate the idea, you have a poor understanding of what it is you are trying to communicate.
• standards - I can't count the times I've seen a diagram and asked myself "what does that person mean?"  Standards work when everyone knows them and everone uses them.  That said, the standards we have are (a) not well known, (b) widely misused, and (c) still being challenged with new attempts at describing the same things, because the existing standard isn't "good enough."  I'm tired of this.  I want there to be a comprehensive set of diagrams that we can all learn about and leverage.  UML is a start, but it misses large areas of model needs.
• primary concern - It is easy to be too detailed by including many different needs in a single diagram.  This should be avoided.  It is better to draw multiple diagrams, one for each use case where it will be used, than to draw a 'mega diagram' that is so rich in content that it requires a two-year course of study to understand it.  Remember this: when building houses, the architect delivers many different diagrams.  Each is used differently.  Frequently the final package of plans will include diagrams with the floor plan many times: framing plan, electrical plan, heating plan, plumbing, etc. They don't just say: it's a floor plan so 100% of the information that CAN go on a floor plan should be put there.  The plumbing subcontractor doesn't need the details that the electrician cares about.  It is time for us, as software architecture professionals, to learn and convey this notion:  create a different diagram for each audience.
• illustrate - we are communicating, and we are looking for feedback.  The goal of the diagram should be to answer a specific question and to share that answer with others to (a) see if they agree, and (b) guide their work.  So, know what it is you want to say, and whose work you intend to influence with it.
• specific set of tradeoffs - the ATAM methodology describes a process whereby software architecture can be peer-reviewed for appropriateness.  It does this by starting with a basic notion: there is no such thing as a 'one-size-fits-all' design.  We can create a generic design, but then we need to alter it to specific situations based on the business requirements.  In effect, we make tradeoffs.  The diagram should make those specific tradeoffs visible.  Therefore, before you create the diagram, be prepared to describe, in words, which tradeoffs you are attempting to illustrate in this model.  If you cannot make a list of the tradeoffs you are illustrating, close your modeling too.  You've jumped ahead.
• tradeoffs inherent in the structure and design - a component is not a tradeoff.  You won't normally get to put a tradeoff in a box and put that box on your model.  Tradeoffs are the first principles that produced your design models, and therefore, when you describe or defend a particular tradeoff, you should be able to refer to your models to defend your position.
• system or ecosystem - modeling in general can be done at different levels of abstraction.  It is reasonable to talk about the architecture of a specific application.  It is also reasonable to talk about the systems of applications needed to delivery a complete business process (like order-to-cash).  It is not reasonable, however, to talk about architecture within a single component.  That is design, not architecture.

I don't know why I felt compelled to write this definition today.  I guess it's just Sunday.  Alas.