I agree with the statement "It's not your definition of architecture that matters, but whay you do with it". An architecture perspective is thus "in the eye of the beholder". Many perspectives seem possible, for example prescriptive and descriptive architecture as a complementary mechanism. The descriptive architecture consists of expressions of as-is and to-be in both natural language constructs and models. The prescriptive architecture is used to guide the transition from as-is to to-be. 
 
Another perspective on architecture is that of a set of overlapping, complementary continua with no clear demarcation points between the continua (see http://archi-works.blogspot.com/2007/07/business-innovation-framework.html) where an experimental framework is explained. In this architecture perspective, each continuum is supposedly supported by a more or less dedicated competence or set of competences.  
 
Where these continua are overlapping or complementary, competences need to collaborate leading to the question: how do we solve our competence gap? In architecture contexts, this is often done with models since not everything can be expressed clearly enough in natural languages only.  
 
Models thus support one way to bridge a competence gap and a new perspective on architecture is born: that of architecture as a competence gap bridge using models and transition rules as a means to add value from competence to competence (leading effectively to a "model value chain")

Here here! We should indeed stop trying to define "architecture" as only one of these perspectives. Furthermore, the "design-oriented perspective" often also serves to regulate lower-level decisions, e.g. in a stepwise refinement, and thus becomes part of the "regulation-oriented perspective".

n response to 'Furthermore, the "design-oriented perspective" often also serves to regulate lower-level decisions, e.g. in a stepwise refinement, and thus becomes part of the "regulation-oriented perspective".':  
 
This is absolutely right! I believe that moving from architecture to engineering, one will elaborate/refine on each of these three perspectives. At architecture level one will have regulations in the form of architecture principles, design artefacts such as ArchiMate models, and associated patterns. When moving to the engineering level, the regulations perspective will be enriched by general principles of sound engineering (referred to as professional principles as Martin Op't Land), as well as more detailed "engineering" regulations. The design oriented perspective and patterns oriented perspective will obviously also see refinement. 
 
In other words, I think the three perspectives are like three "streams" that should be consistent amongst each other, while being refined when moving from architecting to engineering. 
 
I also have a hypothesis on defining the borderline between architecting and engineering, using a goal-oriented approach .... to be worked out in a future blog entry.

It's amazing the debate is still going on. I studied this topic five years ago, and discovered three different flavours too. I named them 
* the prescriptive vision - architecture by decree; 
* the descriptive vision - the (high-level) design is the architecture; 
* the constructive vision - the architecture is a reflection of the design principles. 
 
The descriptive vision is still widespread. You can hear architects in IT talk about the architecture they made, referring to either a 200 page document or a poster on the wall. Managers plan the creation of the architecture as a phase preceding the creation of the design. The implicit logic seems to be that artefacts made by an architect must be architecture. Only think of the documents they call "project-start architecture".  
 
However, when you refer to the origin of architecture, the building industry, you will soon find out that architecture is a concept bound to a construction. Architecture does not exist on paper, nor in decrees, nor in models. A design is a design, a rule is a rule, a pattern is a pattern, and an architecture is neither. 
 
Why is it, that in IT, we tend to hijack a word from another industry, and give it an altogether different meaning? What is a poorly designed architecture (http://www.ibm.com/developerworks/wireless/library/wi-arch7/) different from a poorly designed system? Why do we use the verb "to architect" if we mean "To design intentionally?" Is it just to impress? Well, for me it serves as a disqualifier.  
 
The IEEE working group did a very good job in defining those terms back in 2000. Architecture is a property of a system reflecting its internal cohesion; its harmony with its surroundings and its design principles. Or, officially, "The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." Note that in this definition, a system could be small, like an application, but also big, like an entire enterprise. Either way, a document simply is (part of) a view on the architecture description of the system.  
 
If only IT people would accept (and practice) the difference between an architecture description, a view as part of the architecture description – either made during the design of the system or afterwards – and the architecture itself, much confusion and mystification would be prevented. 
 
Let's end the debate, and start with the real work.

Do you know what a table is? I assume you do.  
How did you get this notion? ....  
Ok, now do this with architecture...