As we know, "IEEE 1471 is an IEEE Standard for describing the architecture of a software-intensive system, also known as software architecture or system architecture." Despite the stress on the 'software-intensive system', I have found that the standard uses the quite consistent definition of 'architecture', which I would like to recommend to use with and without regards to the SW systems.
One of the cornestone elements of the standard is the viewpoint and view. Wikipedia states that the standard "separates the notion of view from viewpoint, where a viewpoint identifies the set of concerns and the representations/modeling techniques, etc. used to describe the architecture to address those concerns and a view is the result of applying a viewpoint to a particular system"
As usual, "the devil is in details" - the content of the viewpoint and, thus, the content of the view depend on... the point of the application.
It is very popular opinion that complex things like Enterprise Architecture may be defined via multiple views on them. I would object this approach: if we do not know what the thing is, i.e. if it is a Black Box, none of the views can fully define the Box's insides; we never can be sure and truly justify that our view is complete and we know all dependencies and relationships between different views on the subject. Dealing with the Black Box, I do not have criteria of truth, i.e. I can see whatever I want in such view. Will this be the trustful definition of the thing?
Here is an example. If I take a 'cost of petrol/gasoline' viewpoint on my car and describe its 'cost of ownership' with related view, will I get a real picture of my car's cost of ownership? My answer is 'NO' because the size of my tank and even gas/mileage (assumed gasoline consumption per mile) ratio do not tell me how costly it will be to provide the gasoline for the car for the next year: I do not know how many miles I will drive and what the cost of the gasoline will be in the those places I drive into. Moreover, the size of the car tank and gas/mileage ratio do not say me anything about particular car gasoline consumption at different driving speed. In other words, the 'cost of petrol/gasoline' viewpoint is not informative enough to define the car 'cost of ownership'.
You might argue that even this 'cost of petrol/gasoline' view gives me some idea about the car's cost of ownership. Yes, it does but how much and reliable is this 'some'? The problem I have with this approach is in that instead of proper position of the viewpoint in the first place, now I have to deal with cloudy 'some' and better manage your expectations about the real cost because you can construct the feeling that given 'some' is good enough to estimate the whole, which is not true in this case. Why I need these problems?
Totally different case takes place when the view is in-out - based on the internal knowledge of the cost of each car part and system involved into petrol/gasoline consumption and power production. Every element of the cost of ownership may be backed with concrete cost of the car part and process. In this case, the view or a model of petrol/gasoline consumption for different cars reflects reality in spite of the viewpoint (size of the tank or engine effectiveness).
This is the reality for Enterprise Architecture (EA) as well. If we allow the use of any out-in view to describe the EA, we look for a nightmare. Assume that CFO takes a financial viewpoint on the EA, does this mean that finance is the part of EA? Or the finance is just an external influencing factor, which accepts some feedback from the EA after placing financial constraints on it? In other words, if we start consider any out-in view on EA as the definition of the EA, it is the 'dead end'. However, if we can keep a balance on the edge between 'definition' and 'description', anyone is certainly free to have any view on the EA as s/he wants (this does not affect what the EA is in reality).
Therefore, the viewpoints and views, so loved by the IEEE 1471 standard, do DESCRIBE but NOT DEFINE the architecture and the Enterprise Architecture, in particular.
To prevent the spread of the wrong interpretation of 'description' as 'definition', the EA should generate a set of views of the architecture for all categories of stakeholders dealing with particular EA. These views have to reflect real internals of the EA under different angles (for different audience); this is the only one integral and consistent way for making a Black Box of EA something more White or Transparent , especially to external stakeholders. So, we have the IEEE 1471 standard with the right words; now our task is to put these words in the right order and into the right context.
This post misses the point. First, the IEEE-1471 model separates the architecture of a system from the architectural description. And yes, the architectural description consists of views. However, the architectural description leaves room for different implementation scenarios. It's not a detailed design. In IEEE-1471 architecture is defined as the fundamental organization of the system [...]. The price of petrol in two years simply is no part of that equation.
Given this fundamental point about architecture, a financial viewpoint still may be valuable. It might contain a description of the necessary investments, the returns and the cost of ownership. It might describe these attributes for different implementation scenario's, for alternative architectures and even for the current state architecture. And of course, if things are still insecure, the estimation might be a price range instead of a fixed price. If different estimations are based on the same premises, the delta still is a relevant decision item. And supporting sound business decisions should be a crucial point for the financial view.
I am afraid, dear TrOttr that it is your comment misses the point of my post, which is about 'views of' vs. 'views on' the architecture.
I read your "architecture of a system" as an implementation of the architecture, not as the architecture per se. Certainly, the same architecture may have many different implementations, I always repeat this. However, if the architecture is separated from its description, this is a trap and a serious problem. All external views ON the architecture always have this 'separation risk'. For internal views OF the architecture, this risk, at least, is minimised.
As of financial viewpoint, it is valuable if it is produced in-out, from inside the architecture and reflects reality. Otherwise, someone can create a view and estimates that exist on the paper only.
You are saying "In IEEE-1471 architecture is defined as the fundamental organization of the system [...]". Yes, but what is so specific in the IEEE-1471's architecture definition that we have to attribute to SW systems? Why we may not apply this definition to any architecture? (this, BTW, does not change my opinion on the 'view OF/ON' the architecture)